[Openmcl-devel] New snapshots available

[Gary Byers]

On Wed, 14 Feb 2007, Phil wrote:

> 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 bug that I'm aware of has to do with the fact that SEND considers
the set of method type signatures in effect when it's used to be closed,
so if "foo" is a message declared to return :int at some point in time,
a (SEND x 'foo) will compile to something that expects an integer
to be returned and doesn't expect any sort of ambiguity.

If new interfaces are loaded (after that first SEND was compiled) and
some disjoint class defines a method on FOO that returns :FLOAT, then
any subsequent SEND -should- consider the message to have an ambiguous
type signature and should expand into code which does runtime typechecking
of the receiver and does a CASE or COND or something to select the
right implementation.

The original SEND - compiled in a simpler world - won't get recompiled.

Is this what you're referring to ?  Or are there other cases which
lose ?

>
>> - 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?

Yes (at least in theory); the general idea would be to do something
similar to what's done for "init" methods now (try to map a signature
to a compiled helper function that knows how to do ff-calls of that
signature, maybe create that function at runtime if it didn't already 
exist, and funcall the helper function.)

%SEND basically tried to build the arguments to to CCL:%FF-CALL and
call it.  That worked reasonably well on ppc32 Darwin (it was at
least Turing-complete), since sending a message ultimately just
involved doing a foreign function call and making sure that the
arguments and result wound up in the right place.  On other platforms,
dealing with structure arguments/return values requires a lot of
additional complexity wrapped around the (simple) foreign function call,
and it'd be difficult for %SEND (or something like it) do decide what
to wrap around that call and how to do it.

>
> Thanks,
> Phil
>