All right, all right! Interim decision regarding qualified Object methods

[David Piepgrass]

On Thursday, 12 July 2012 at 17:51:32 UTC, Andrei Alexandrescu 
wrote:
> On 7/12/12 1:40 PM, David Piepgrass wrote:
>> 1. Most importantly, the C++ template approach is a big pain 
>> for
>> large-scale systems, because in such systems you want to 
>> create DLLs/SOs
>> and C++ has neither a standard ABI nor a safe way to pass 
>> around
>> template instantiations between DLLs (in the presence of 
>> changes to
>> internal implementation details). Similar problems exist for 
>> D, yes?
>> It's a lot easier to define a standard ABI for classes than to 
>> solve the
>> cross-DLL template problem.
>
> The thing is, that can be done in an opt-in manner. People who 
> want methods in the root of the hierarchy can define a root 
> that defines them. But there's no way to opt out of inheriting 
> Object. Basically it's nice to not force people to buy into a 
> constrained environment without necessity.

But is the constrained environment we're talking about really all 
that constrained?

- 'const' is not overly harsh if the user has machanisms to make 
that mean 'logical const'.
- regarding the 5 vtable entries (destructor, toString, toHash, 
opEquals, opCmp), well, that's only 20/40 bytes per process, and 
maybe we don't need opCmp that much.

Although having these in Object seems constraining in one way, 
removing them is constraining in a different way: you can no 
longer provide collection classes for "any" object without 
involving templates.

Wait a minute, though. Keeping in mind the problem of DLL 
interoperability, and the constraints on using templated + many 
DLLs together, what if D introduced the feature that Go and Rust 
have, the ability to adapt any object to a compatible interface?

interface IComparable {
    bool opEquals(IComparable rhs);
    int opCmp(IComparable rhs);
}

class Foo { /* could contain anything */ }

So let's say we remove all the methods from Object, but we still 
want people to be able to make a collection of "any object", such 
as Foo, and pass this collection between DLLs safely. Moreover we 
want only be a single instance of the collection class, defined 
in a single DLL (so this collection cannot be a template class).

Since a class Foo does not declare that it implements 
IComparable, and it might not even contain opCmp() and 
opEquals(), we can't just cast to IObject. Not in the current D, 
anyway.

But now add interface adaptation from Go/Rust. Foo might not 
define opEquals and opCmp itself, but any client can add those 
via UFCS, and the standard library would probably define opEquals 
via UFCS as reference equality already. Thus it is possible for 
any client to pretend that any class implements IComparable, by 
adding the missing pieces (if any) and casting to IComparable.