On Friday, 23 March 2018 at 21:55:52 UTC, Jonathan M Davis wrote:
> On Friday, March 23, 2018 21:45:14 12345swordy via Digitalmars-d wrote:
>> [...]
>
> Walter and Andrei have been discussing putting together a DIP with a "ProtoObject" which will be the new root class below Object where ProtoObject itself has only the bare minimum required to work as a class (not monitor object, no toString, no opEquals, etc.). Classes could then derive from ProtoObject directly instead of from Object, and then they could define any of the functions that are currently on Object with whatever attributes they wanted (or not define them at all). The DIP has not yet been written, and the details still need to be ironed out, but that's the gist of the direction that's currently being considered.
>
> - Jonathan M Davis

That what I have read from github. However the disadvantage of this is that you can not longer make assumptions of what default methods that they support.

On Fri, Mar 23, 2018 at 10:40:36PM +0000, 12345swordy via Digitalmars-d wrote:
> On Friday, 23 March 2018 at 21:55:52 UTC, Jonathan M Davis wrote:
> > On Friday, March 23, 2018 21:45:14 12345swordy via Digitalmars-d wrote:
> > > [...]
> > 
> > Walter and Andrei have been discussing putting together a DIP with a "ProtoObject" which will be the new root class below Object where ProtoObject itself has only the bare minimum required to work as a class (not monitor object, no toString, no opEquals, etc.). Classes could then derive from ProtoObject directly instead of from Object, and then they could define any of the functions that are currently on Object with whatever attributes they wanted (or not define them at all). The DIP has not yet been written, and the details still need to be ironed out, but that's the gist of the direction that's currently being considered.
> > 
> > - Jonathan M Davis
> 
> That what I have read from github. However the disadvantage of this is that you can not longer make assumptions of what default methods that they support.

I don't think that's a problem.  I presume the default would still be to inherit from Object when the class declaration doesn't explicitly specify ProtoObject.  The assumption that any Object has toString, etc., would still hold for all existing code. ProtoObject would (almost) be like a separate hierarchy altogether.

The only potential problem I can see is that some code that used to test for `is(T == class)` may now have to be changed to `is(T : Object)` if the purpose of the test was to check whether Object methods like toString, etc., are available.


T

-- 
Gone Chopin. Bach in a minuet.

On Friday, March 23, 2018 22:33:53 jmh530 via Digitalmars-d wrote:
> On Friday, 23 March 2018 at 21:55:52 UTC, Jonathan M Davis wrote:
> > [snip]
> >
> > Walter and Andrei have been discussing putting together a DIP with a "ProtoObject" which will be the new root class below Object where ProtoObject itself has only the bare minimum required to work as a class (not monitor object, no toString, no opEquals, etc.). Classes could then derive from ProtoObject directly instead of from Object, and then they could define any of the functions that are currently on Object with whatever attributes they wanted (or not define them at all). The DIP has not yet been written, and the details still need to be ironed out, but that's the gist of the direction that's currently being considered.
> >
> > - Jonathan M Davis
>
> Object would derive from ProtoObject, right?

That would be the idea. That way, if all goes well, no code would break, and hopefully, over time, Object would be treated as legacy and phased out of use (though Andrei has stated that it's not his plan that Object actually be deprecated). Newer code would derive from ProtoObject rather than Object, and we'd have the flexibility with the functions that come from Object that we've wanted for years, because then they can be defined as appropriate by sub-classes of ProtoObject.

- Jonathan M Davis

On Friday, March 23, 2018 16:18:14 H. S. Teoh via Digitalmars-d wrote:
> On Fri, Mar 23, 2018 at 10:40:36PM +0000, 12345swordy via Digitalmars-d
wrote:
> > On Friday, 23 March 2018 at 21:55:52 UTC, Jonathan M Davis wrote:
> > > On Friday, March 23, 2018 21:45:14 12345swordy via Digitalmars-d
wrote:
> > > > [...]
> > >
> > > Walter and Andrei have been discussing putting together a DIP with a "ProtoObject" which will be the new root class below Object where ProtoObject itself has only the bare minimum required to work as a class (not monitor object, no toString, no opEquals, etc.). Classes could then derive from ProtoObject directly instead of from Object, and then they could define any of the functions that are currently on Object with whatever attributes they wanted (or not define them at all). The DIP has not yet been written, and the details still need to be ironed out, but that's the gist of the direction that's currently being considered.
> > >
> > > - Jonathan M Davis
> >
> > That what I have read from github. However the disadvantage of this is that you can not longer make assumptions of what default methods that they support.
>
> I don't think that's a problem.  I presume the default would still be to inherit from Object when the class declaration doesn't explicitly specify ProtoObject.  The assumption that any Object has toString, etc., would still hold for all existing code. ProtoObject would (almost) be like a separate hierarchy altogether.

Yeah. The fact that Object has those functions has been a huge liability, and with templates, it's completely unnecessary to have them on Object for stuff like containers to work. Any code that needed to depend on a particular set of functions in a base class would need to use whatever that base class was, but then each code base could define that hierarchy base on what made sense for it rather than forcing one set of attributes on the entire language. Existing code that used Object in that fashion would continue to work.

> The only potential problem I can see is that some code that used to test for `is(T == class)` may now have to be changed to `is(T : Object)` if the purpose of the test was to check whether Object methods like toString, etc., are available.

Presumably, that will have to be covered as part of the DIP. I don't know how big a risk such issues pose, but they will have to be explored.

Overall though, if we go with something like ProtoObject, it will solve a lot of the problems that we've had with Object. Several years ago, we decided that the various functions on Object should be removed, because they were causing too much trouble, but for various reasons, that's never happened even though it was agreed that that was the best way to go. ProtoObject would essentially be a way to go that route without actually breaking Object.

Regardless, remember that nothing here is definitive yet. ProtoObject is just the direction that Andrei would like to take things, and Walter has agreed that we should have a DIP that explores the options appropriately. The details are still very much in flux. So, we'll have to wait and see, but I think that this is a promising turn of events.

- Jonathan M Davis