Feedback Thread: DIP 1042--ProtoObject--Community Review Round 1

[Elronnd]

This does not retain backwards compatibility, because 'Object' 
can no longer be counted upon to be a supertype of all class 
instances.

Suppose I maintain library X, which does some work on Objects.  
It simply treats Object as a top type (for classes), without 
using any special functionality.  Somebody else maintains library 
Y, which defines a few classes.  This DIP is approved, and the 
library Y maintainer decides they don't need hashes, so they 
redefine their classes in terms of ProtoObject rather than Object.

This is fine; hashing was not an advertised part of their API, 
and no one was using it anyway.  No one's code broke as a result 
of this.  I would nominally feel very comfortable making such a 
change and would not consider it a compatibility break.  _Except_ 
that, when a user tries to combine libraries X and Y, their code 
will break.

Hence, while this change does avoid breaking any code as such, it 
forces that breakage straight into userspace, and does so in a 
forceful fashion which does not really permit deprecation 
periods.  Moreover, I do not have any way to update library X in 
a manner which retains compatibility, as even if I switch from 
processing Objects to ProtoObjects, this breaks compatibility if 
I ever return such an object.

------------------------------

Suppose that, instead, we make 'Object' the empty top type as 
well as the default superclass.  This is a compatibility break, 
and is therefore much scarier.  But practically, there will be 
much less silent breakage, because problems will manifest where 
they are actually located.