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