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

[Elronnd]

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).