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