#dbugfix 17592

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Mar 23 23:18:14 UTC 2018


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.


More information about the Digitalmars-d mailing list