typeid() broken for interfaces?
foobar
foo at bar.com
Tue Dec 4 08:35:23 PST 2012
On Tuesday, 4 December 2012 at 13:47:39 UTC, Paulo Pinto wrote:
>> Generally speaking you are right. But specifically regarding
>> toString, what would you suggest?
>> Should each and every Interface have a toString method?
>
> Yes for each interface where you intend to call toString().
That's a lot of duplication considering D already provides this
in Object.
>
>> Should we have an IObject Interface that all classes are
>> required to explicitly inherit?
>> The purpose of having a root Object class is to define the
>> _common interface of all objects_. Why else have such a class
>> in the first place?
>
> For languages without generics where you need a common base
> class to place in containers.
That's only one reason. Other reasons are to provide a common
interface for all objects. Anyway, we are discussing the current
D design and not other possible designs such as the one in C++.
>
>> Requiring an explicit cast to Object makes sense only in a
>> no-single-root design such as the one in c++ which D sensibly
>> chose not to copy.
>>
>> We can have a separate debate what should the root Object
>> define, but there should not be a requirement to explicitly
>> cast any object to it.
>
> The whole point of interfaces is to have explicit dependencies
> of
> methods, properties, variables across the inheritance tree.
>
> Actually there was a discussion some months ago about what
> methods still
> made sense to expose via object, given D's templates.
>
> --
> Paulo
Given D's _current_ design, all objects should implicitly cast to
Object.
It's plain common sense - If we have a root class that all other
classes inherit from than it logically follows that all class
instances can be implicitly & safely converted back to that root
class (Object).
What you are arguing is whether the current design of D of
defining Object makes sense in the first place. I'm arguing that
_given the current design_ the language is inconsistent and has a
design flaw.
More information about the Digitalmars-d
mailing list