ronaldoussoren / pyobjc

The Python <-> Objective-C Bridge with bindings for macOS frameworks
https://pyobjc.readthedocs.io
563 stars 47 forks source link

wrong method part of wrong class #578

Closed nullhook closed 11 months ago

nullhook commented 1 year ago

I'm confused about how serializeToURL_error_ being part of _MTLLibrary. If you look at Metal.hpp headers this function is part of other classes but not MTLLibrary. In conclusion, its producing wrong results.

are the bindings here auto generated?

nullhook commented 12 months ago

@ronaldoussoren is this the byproduct of https://github.com/ronaldoussoren/pyobjc/issues/475 ?

ronaldoussoren commented 12 months ago

The bindings inspect the Objective-C runtime for methods, with manual additions for methods with non-trivial signatures (such as pass-by-reference arguments). This means that the Objective-C classs _MTLLibrary implements -[serializeToURL:error:].

As _MTLLibrary is not a public class, and the MTLLibrary Objective-C protocol does not specify a -[serializeToURL:error:] selector the manual additions do not have data for the output argument of this selector.

This is not related to #475.

ronaldoussoren commented 12 months ago

What are you trying to do and what problem to you run into?

In general you should limit yourself to the API described in Apple framework documentation (Objective-C version). Classes may have any number of undocumented APIs, some of which with public names.

nullhook commented 12 months ago

created a MTLLibrary instance and used serializeToURL to save on disk. this worked fine till some machines (macbook air, apple silicon) upgraded to macOS 14.

basically, used a method that wasn't exposed and it ran successfully till the new macOS upgrade. i was looking all over c++ drop-in headers to find serializeToURL method but they're not part of MTLLibrary at all and it's not documented anywhere. it's interesting that some of these unexposed methods work.

perhaps scanning all .Frameworks headers and marking the ones that aren't exposed as "unexposed_fn_name" would be helpful but i'm assuming it's not as trivial it looks.

ronaldoussoren commented 11 months ago

perhaps scanning all .Frameworks headers and marking the ones that aren't exposed as "unexposed_fn_name" would be helpful but i'm assuming it's not as trivial it looks.

That's not how PyObjC works. The advantage is that accessing Objective-C classes mostly just works, the disadvantage is that you might accedently use private APIs that aren't clearly marked as such.

Some day I'll get around to implementing support for static typing and that should help detecting accessing undocumented methods. But, adding static typing support is easier said than done due to how some ObjC features are exposed to Python and protocols is one of those.