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).

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).

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).

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

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?

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

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 ?