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

[RazvanN]

On Tuesday, 11 January 2022 at 12:35:33 UTC, Elronnd wrote:
> On Tuesday, 11 January 2022 at 09:33:16 UTC, RazvanN wrote:
>> Are you referring to the case where a method from library Y 
>> returns
>> an instance of something that inherits ProtoObject (but not 
>> Object)
>> and then when the instance is passed to some_function in 
>> library X,
>> some_function might make assumptions that are false about the 
>> instance
>> (for example, assumes that the instance has a toHash)?
>
> Not quite.  I am referring to the case where library X uses 
> Objects _without_ expecting them to have a toHash (because it 
> predates ProtoObject; that is, it does not use templates); and 
> library Y used to return Object instances, but then switches to 
> returning ProtoObject instances.
>
> This seems like a very reasonable change from library Y's 
> perspective, because nobody was relying on any particular 
> behaviour from its hash.  The issue is that this actually 
> breaks compatibility, but that's far from obvious to library 
> Y's maintainers.
>
> Additionally, library X can not transition to using 
> ProtoObjects without breaking compatibility.  If either of 
> library X and library Y transitions to using ProtoObjects, code 
> using them may break.  The only way forward is if _both_ 
> transition.  This is why I don't think the DIP delivers on its 
> promise of backwards compatibility.  Is it worse to pin your 
> compiler version than to pin a substantial subgraph of your 
> dependencies, when you can reasonably expect the former 
> solution to result in less time spent on old versions?
>
> If instead we make it so that Object is the empty root object, 
> then more code will be broken, but it won't happen that a 
> change in library Y can break library X (modulo templates, of 
> course).

I think that the fundamental idea here is that when the library 
owner
switches from Object to ProtoObject that is a breaking change 
that should
be advertised, because he is changing the API. The library owner 
should
either release a new major version or provide the same utilies as 
Object.
The idea here is that you do not know what your users are doing; 
even without
library X, the user can simply call toHash because Object used to 
have it.