typeid() broken for interfaces?

[foobar]

On Wednesday, 5 December 2012 at 16:21:55 UTC, Jonathan M Davis 
wrote:
> On Wednesday, December 05, 2012 15:11:55 foobar wrote:
>> On Tuesday, 4 December 2012 at 18:41:14 UTC, Jonathan M Davis
>> 
>> wrote:
>> > On Tuesday, December 04, 2012 17:35:23 foobar wrote:
>> >> That's a lot of duplication considering D already provides 
>> >> this
>> >> in Object.
>> > 
>> > Though per the last major discussion on const-correctness and
>> > Object, it's
>> > likely that toString, toHash, opCmp, and opEquals will be
>> > removed from Object,
>> > in which case you'd need a derived class which implemented 
>> > them
>> > to use any of
>> > them.
>> > 
>> > - Jonathan m Davis
>> 
>> In other words, the plan is to pretty much deprecate Object? I
>> hope there would be appropriate replacement before this 
>> happens.
>> Users should be able to have a standardized API and a default
>> implementation for these methods.
>> Is phobos going to introduce interface such as Printable,
>> Comparable, etc.. ? (names tentative, I'm more worried about 
>> the
>> semantics).
>
> No. The plan is not to deprecate Object. The reality is that 
> those functions
> don't need to be on Object in D, because all of the runtime 
> stuff that relies
> on them can (and really should) be templatized, whereas in Java 
> or C#, they
> have to put them on Object and operate through Object. What we 
> have currently
> have with Object in D is a case of having copied too much from 
> Java and C#
> (and templates weren't as good in D1, possibly making those 
> functions
> necessary there). And having those functions on Object has 
> created a lot of
> problems with regards to stuff like const. If they're there, 
> they have to be
> const so that you can compare const objects, but given how D's 
> const works,
> that then make certain idioms impossible in classes (e.g. lazy 
> loading member
> variables and caching). const needs to work, but we can't force 
> it on people,
> and putting it on Object forces it on people. Rather, it's 
> perfectly possible
> for only derived classes to have those functions. They can then 
> use the
> function attributes that match what they need, and stuff like 
> druntime's
> opEquals or AAs will just be appropriately tempatized and work 
> with the
> derived classes without needing to have any of that on Object. 
> There's really
> no need to have any of that on Object.
>
> I'd have to go digging through the archives to find the last 
> discussion on
> const-correctness where this was discussed in some detail, but 
> that's the gist
> of it. Putting those functions on Object causes a lot of 
> problems with regards
> to function attributes, and templates make actually putting 
> those functions on
> Object unnecessary.
>
> - Jonathan M Davis

But these are the methods of Object. So even if Object itself 
remains it looses its meaning. So are we going to keep Object 
just for backwards compatibility? Is there any point left keeping 
the single root design?