#dbugfix 17592

Jonathan M Davis newsgroup.d at jmdavisprog.com
Fri Mar 23 23:35:02 UTC 2018


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



More information about the Digitalmars-d mailing list