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

[RazvanN]

On Thursday, 13 January 2022 at 17:57:24 UTC, David Gileadi wrote:
> Based on RazvanN's reply to Elronnd (quoted for context):
>
>> 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.
> If this change leads each of my dependencies to make breaking 
> changes then its backwards compatibility certainly isn't the 
> "no breaking changes" claimed by the DIP. This effect on users 
> of third-party libraries should be called out in the DIP's 
> Breaking Changes and Deprecations section.
>
> (I'm replying to the original post here because my original 
> reply violated Feedback rules; sorry about that).

I think that this case is being exaggerated here. I find it hard 
to believe
that people write libraries where they simply type a parameter as 
being
Object. Most library code is templated which means that the 
received types
can be either class, struct or basic types. As such, I would 
expect that
folks would at least test for the existence of the likes of 
toHash, opCmp etc.
before using them.

My expectation is that, in most cases, updating to ProtoObject 
will not incur any breaking changes, however, there might be a 
few situations where users (arguably, wrongfully) were using the 
builtin object methods of class instances from library X. In this 
scenario, you will end up with a compile error in user code after 
upgrading. I would argue that this is for the best if the library 
owner did not intend to expose those facilities.