Feedback Thread: DIP 1042--ProtoObject--Community Review Round 1
RazvanN
razvan.nitu1305 at gmail.com
Tue Jan 11 12:47:17 UTC 2022
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.
More information about the Digitalmars-d
mailing list