View mode: basic / threaded / horizontal-split · Log in · Help
December 05, 2012
Re: typeid() broken for interfaces?
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).
December 05, 2012
Re: typeid() broken for interfaces?
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).
December 05, 2012
Re: typeid() broken for interfaces?
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 interfaces such as Printable, 
Comparable, etc.. ? (names tentative, I'm more worried about the 
semantics).
December 05, 2012
Re: typeid() broken for interfaces?
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
December 06, 2012
Re: typeid() broken for interfaces?
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?
December 06, 2012
Re: typeid() broken for interfaces?
On Thursday, December 06, 2012 12:03:14 foobar wrote:
> 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?

It's would still be perfectly possible to pass around Object if you wanted to. 
You just couldn't call much on it without casting it to something else first. 
Perhaps there's less reason to have it, but no one ever suggested that we get 
rid of it. Having those functions on Object has harmed us. Having a common 
base type hasn't.

But much as it was decided on, nothing has happened yet, so who knows how the 
transition will be done.

- Jonathan M Davis
December 06, 2012
Re: typeid() broken for interfaces?
On Thursday, 6 December 2012 at 11:03:15 UTC, foobar wrote:
> 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?

I don't see any major drawback in keeping Object. What are the 
drawbacks ?
Next ›   Last »
1 2 3 4 5
Top | Discussion index | About this forum | D home