DIP in making: ProtoObject

SimonN eiderdaus at gmail.com
Wed Apr 4 11:03:29 UTC 2018


On Wednesday, 4 April 2018 at 04:49:10 UTC, Andrei Alexandrescu 
wrote:
> This is not officially reviewable yet, but conveys the gist and 
> could use some early feedback. Any insight will be appreciated.

I'm delighted to see this DIP! Best of luck.

If there is a root class, I agree that it should be empty. What 
are some good reasons to keep the root class?

Associative arrays with immutable key classes rely on opEquals, 
opCmp, toHash. When a class derives from ProtoObject and an AA is 
declared, the compiler should statically check whether opEquals, 
opCmp, toHash are implemented, most likely via 
template/duck-typing, or maybe by interface. I feel there is no 
need to tailor ProtoObject towards AAs; that's good.

It's popular to wrap class references in templated structs that 
then masquerade as class references: std.typecons.Rebindable, or 
aliak's Optional, or maybe something to enforce a custom 
restriction at runtime (reference is not null!). These templated 
structs rely on is(T == class), and it takes a lot of 
implementation code to make these structs blend in with raw class 
references. const, inout, opEquals, ..., many things can subtly 
get in the way. Covariant return types become impossible.

It feels correct to disallow `a == b` entirely for a, b 
ProtoObjects, even though is(T == class)-templated structs will 
break when they forward opEquals explicitly. It would be nice to 
find a catch-all resolution that makes all existing is(T == 
class)-templates work with ProtoObject, but I doubt there will be 
one.

-- Simon


More information about the Digitalmars-d mailing list