Le 11 avr. 08 à 14:19, Philip Aker a écrit : On 08-04-11, at 03:27, Jean-Daniel Dupas wrote: Le 11 avr. 08 à 11:49, Jack Small a écrit :
The point, if I may be so bold, would be to create a dynamic object exchange in order to bridge disparate object models in a simple but robust way. Something that generic, one-way bridges can never do. The whole point would be to have a plain C interface. No defines or macros or new semantics. It would seem logical to make it part of CoreFoundation and provide a platform agnostic interface for developers that need to maintain code bases in several operating systems.
There is something I do not understand. Building a true object oriented (with polymorphism and inheritance) plain C framework is like reinvent Obj-C runtime + Cocoa. The thing you describe
The aspect Jack describes is something I assumed was self-evident. For a dynamic implementation, this was really out of reach to C before CoreFoundation and CarbonEvents. If I could characterize the discussion of the solution rather straight-forwardly, the entry point is akin to have made a scriptable Carbon application (no Cocoa AE). That is to say, a serious contemplation of the AppleEvent object model in practice and subsequently, it's adaptability for the purpose of upgrading CFTypeRefs to be more compatible with NSObject introspection capabilities. For instance Chris Nebel (Automator and AppleScript engineer) has stated that it would be so much easier if key 'from' - { -1 } 'null': null descriptor
didn't entail a process descriptor, but rather be what 'item' is to the Cocoa scripting inheritance chain.
Ok, Thank you, i better understand your solution. |
