[Openmcl-devel] New snapshots available

[Phil]

Gary,

Great to see progress on supporting Leopard/Obj-C 2.0.  I did have a  
couple of questions re: the release notes...

On Feb 14, 2007, at 5:32 AM, Gary Byers wrote:

> - There are new interface files for all platforms.  These files
>    encode some foreign type information a little differently
>    than older ones did (notably information about foreign functions
>    that return structures or accept structure args by value.)  The
>    new .cdb files can't be used by older versions of OpenMCL; using
>    older .cdb files with this version is "allowed, but not supported
>    or recommended."

Do any of the changes made address the issue of multiple signatures  
for a method (i.e. size, display, etc.) which result in ambiguous  
return types?

> - The ObjC bridge has had a long-standing bug whereby a standalone
>    Cocoa application may have needed to find the interface databases
>    at runtime in order for MAKE-OBJC-INSTANCE and MAKE-INSTANCE of
>    an ObjC class to work.  (These functions needed to be able to
>    send an "init" message to the newly-allocated instance, and needed
>    to know the type signature of that init message in order to do  
> that.)
>    The current scheme tries to avoid this by pre-compiling helper
>    functions to enable calling all known "init" message signatures.
>    (More accurately, all fixed-argument "init" message signatures.)
>    This scheme avoids the need to send messages whose argument
>    and result types are computed at runtime (via %SEND), and %SEND
>    (a) was known to be inefficient and (b) would have a lot of
>    difficulty handling all known structure return/passing conventions
>    on supported platforms.  Accordingly, %SEND has been deprecated
>    (with extreme prejudice, e.g., removed.)

Ugh... I was using %SEND.  Is there a way to accomplish the following  
without %SEND: take an arbitrary object (unknown at compile-time),  
either look at the type of the object or a list of methods for the  
object, and call a series of methods belonging to a list or matching  
a pattern?

Thanks,
Phil