[Openmcl-devel] Re: slot-value != struct-ref? (never mind)

[Gary Byers]

On Mon, 30 May 2005, alex crain wrote:

>
> Having now embarrassed myself, I retract my question.
>
> (objc-message-info-flags foo) is not supposed to equal (objc-method- 
> info-flags foo).
>
> I guess that I just need glasses.
>
> :alex
>
>

Personally, I find that signals get from the optic nerve to the brain
OK.  After that point, it's anyone's guess what happens to them ...

I -think- that it's the case that there are about a dozen actual cases
of ambiguity in the set of declared messages (those that come from the
header files and from lisp-implemented methods); when I started to
work on this a few weeks ago, I found that there were several cases
where a lisp-implemented method introduced ambiguity (often because
a subclass method returned :VOID when the parent returned :ID, or
vice versa.)  I -think- that this is actually illegal (if two or
more methods on a different ObjC message have different type signatures,
the classes they're defined on should be disjoint.  I think ...)

You're right, though, that when ambiguity exists and both class and
instance methods are present, the CASE or COND that handles the
ambiguity has to take this into account (and the current
implementation doesn't do so.)  This situation is perfectly legal, but
I don't think that it's present in the set of declared messages.

The TODO list that I'm aware of includes:

  - handling the class/instance case of ambiguous messages
  - handling cases where the message name isn't known at compile-time
    (this happens in MAKE-INSTANCE and MAKE-OBJC-INSTANCE), either
    by calling %FF-CALL at runtime or by calling a precompiled function
    associated with the method's signature.  Randy had some code that
    implemented the other strategy; I think that it's still present
    in the bridge sources (it was intended to be used in code which
    integrates ObjC methods and CLOS generic functions; that code's
    currently disabled, but - further down the TODO list - it's worth
    revisiting)
  - removing the remaining pieces of the old SEND implementation (which
    derives method/message information from the ObjC runtime)
  - removing some of the "manual" class declarations of internal classes
    that are there to keep the old SEND implementation happy.
  - recognizing and handling internal (undeclared) classes and instances
    (e.g, we want to treat an NSCFString as if it were an NSString, and
    don't want to have much of any persistent knowledge of the internal
    NSCFString class.)

The latter few points mean that we want to make the CASE/COND which
handles ambiguity use ObjC runtime primitives (rather than CLOS) to
determine the class of an object (since its ObjC class may be some
private - aka "undeclared" - thing that we've never heard of.)  There's
some data structure that records undeclared classes that are found
to exist at runtime; these private/internal classes are supposed to
be mapped to the their nearest declared ancestor (so we -could-
make CLASS-OF return the NS:NS-STRING class when applied to something
that's actually an NSCFString.)

This distinction between "declared" and "internal" classes and methods
is important; I think that it makes the issues of portability between
OS releasess (and -slightly- different method/class hierarchies) a
lot more tractable.

I've been planning on getting to the TODO list above Real Soon Now
(and that's been the plan for the last few weeks)