Issue with bindings due to KVO changes...

[gcasa]

https://github.com/gcasa/NSTreeController_test
https://github.com/gcasa/NSBrowser_bindings_test

Botn of these test NOW FAIL due to the latest changes. I am trying to fix this, but it is confusing as to why it breaks as the method appears to be defined. FRUSTRATED WITH CONSTANT BREAKAGE

[gcasa]

The issue is that it's saying that setKeys:triggerChangeNotificationsForDependentKey: is not recognized on the class object. :/

[gcasa]

[triplef]

Good catch @gcasa. Your code seems to be using the old setKeys:triggerChangeNotificationsForDependentKey: method (deprecated by Apple for a while), which is not supported in the new KVO implementation.

We can look into adding support for that. In the meantime you could do one of these to work around:

• Update to the newer -keyPathsForValuesAffectingValueFor<Key> methods, which are supported by the new KVO implementation
• Build libs-base with --disable-newkvo

[gcasa]

@triplef I'm not sure I see a clear reason why the two implementations need to be incompatible. This is a breaking change that causes bindings to be broken. The code in question is in NSTreeController and NSObjectController, which has been functional up until now.

Here is what Apple Documentation says on this...
"The default implementation of this method searches the receiving class for a method whose name matches the pattern +keyPathsForValuesAffecting, and returns the result of invoking that method if it is found. Any such method must return an NSSet. If no such method is found, an NSSet that is computed from information provided by previous invocations of the now-deprecated setKeys:triggerChangeNotificationsForDependentKey: method is returned, for backward binary compatibility."
https://developer.apple.com/documentation/objectivec/nsobject/1414299-keypathsforvaluesaffectingvaluef

So the deprecated method you mentioned should still work. The general approach on this project is not to deprecate methods unless necessary. Even given what Apple is saying, as a developer, I would expect the setKeys:... method to still work.

[triplef]

You’re right there’s no reason. The new KVO implementation is a complete rewrite, because the old one had many issues and the new one was based on code from WinObjC, and the omission of that deprecated method was just not caught during implementation, reviews, or tests.

[gcasa]

It's understandable, as it's a huge effort. I'm very thankful for the improved implementation. I hope it's better and more efficient. We need to have another file, perhaps NSKVODeprecated.m or something to hold the implementations that are out of date.

[gcasa]

Or NSKVOLegacy.m... whatever. :)

[rfm]

Bear in mind that, because the new implementation really can't work with the gnu runtime, the GUI library can't depend on features exclusive to it and will need to be tested with both GCC/gnu and Clang/ng :-(

…

On 10 Dec 2024 at 16:00, Gregory Casamento ***@***.***> wrote: Or NSKVOLegacy.m... whatever. :) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[gcasa]

Bear in mind that, because the new implementation really can't work with the gnu runtime, the GUI library can't depend on features exclusive to it and will need to be tested with both GCC/gnu and Clang/ng :-(

No one is advocating that gui depend on any features exclusive to GCC.

My point is this... Apple supports the old method by implementing it in terms of the new one. We should be able to do the same. Simple.

I will change GUI to use the new method as it seems more efficient. My concern, however, is that there may be other applications or tools used by other users that this change breaks.

[gcasa]

@triplef one note... I realize Algorridim doesn't use the GUI, but you still need to be careful not to break it.

[hmelder]

I'm not sure I see a clear reason why the two implementations need to be incompatible.

They are not. I just opted not to reintroduce a long (since 10.5) deprecated API. Given that the new KVO implementation is tied to libobjc2, I am tempted to say that most code bases affected never used, or have long migrated.

[hmelder]

but you still need to be careful not to break it.

Difficult to do, if there is no CI.

[gcasa]

I'm not sure I see a clear reason why the two implementations need to be incompatible.

They are not.

They are not compatible by demonstration, per the breakage in the GUI. However, as the previous implementation (which appears to be more general since it works on both GCC and Clang) contains both, I believe adding this method is achievable.

I just opted not to reintroduce a long (since 10.5) deprecated API. Given that the new KVO implementation is tied to libobjc2, I am tempted to say that most code bases affected never used, or have long migrated.

As I said above in my previous reply, this is not the policy on this project. Generally, APIs are kept. We still have APIs from OPENSTEP that have been dropped from Cocoa. Also... while this API is deprecated it is STILL PRESENT in Cocoa which makes my point even stronger that it should still be there.

I will make this easy on you guys... I'll add the implementation in libs-base myself. sigh

[gcasa]

but you still need to be careful not to break it.

Difficult to do, if there is no CI.

You are not limited to CI for your testing. Given that this change affects bindings, that should have been included in the things that needed to be tested. The bindings implementation has been in GUI for a while.

Also, I could swear that this was the subject of our last discussion when there was breakage then as well. Just to underscore the difference here, @hmelder is correct... this likely doesn't have as wide an impact, so this doesn't fall into the same category as that issue did.