Re: [Etoile-dev] ANN: New Objective-C Runtime

[Quentin Mathé]

Hi David,

Le 8 nov. 07 à 16:03, David Chisnall a écrit :

> Hi Everyone,
>
> I've spent the last two days locked in my room doing some therapeutic
> coding[1], and the result is a new Objective-C runtime (rejection is
> obviously good for my productivity; I should apply for more jobs).

:-)

>  A
> quick summary of features:
>
> - Two layer model, with Self-like object model at the core and classes
> built on top.
> - Very small code base (roughly 10% of the size of the GNU runtime)
> - Support for @synchronized on all objects / classes.
> - Support for concrete protocols / mixins.
> - Support for prototype-based object orientation (can be mixed with
> class-based; classes really are just another kind of object in this
> runtime)
> - Support for safe method caching (including polymorphic inline
> caching) with low overhead.
> - Support for fast accessor methods (we can implement properties that
> are much faster than Apple's)

As we already discussed it, I really like the whole design except the  
fact protocols are only available at class level.
I may submit a patch later to implement them at object level. Class  
would override protocol handling to handle the case where you pass a  
protocol which is a class and not an object. In this former case, the  
handling would be extended to deal with instance and class methods at  
the same time rather than only instance methods.

> The code is currently in a branch in the Étoilé repository:
>
> svn://svn.gna.org/svn/etoile/branches/libobjc_tr/
>
> Comments welcome, bug fixes very welcome.

I may have overlooked something, but after reading objc_object.h and  
message sending mechanism, I fail to understand how Io messaging model  
can be fully supported by libobjc_tr.

#define MSG_SEND(ret, obj, sel_name, sel_types, ...)\
                do\
                {\
                        static SEL selector = lookup_typed_selector(sel_name, 
sel_types);\
                        struct objc_slot * slot = slot_lookup(object, foo_sel);\
                        CALL_SLOT(ret, slot, obj, selector, __VA_ARGS__);\
                } while(0)

Passing only obj (receiver), sel (selector) and arguments seems too  
much limited since you cannot know anything about where the message is  
sent either in the lookup function or in the call function.
I suggest a different implementation at the end of this mail. But  
before that, I'm going to explain what is libojc_tr problem in my  
opinion if you want to support Io messaging or other uncommon  
messaging styles


Inside a each block/method, Io provides access to the sender and the  
receiver context in addition to self. There is a call object that you  
can access. Here is the core API of Call prototype:
- sender // the context/namespace where the message sending was executed
- message // the invocation object
- activated // the method/block object
- slotContext // the context/namespace where the message was received  
(for example the parent/proto which implements the method if the  
receiver doesn't)
- target // the receiver aka self

/* do means: execute  code in the context of the receiver  
(ParentObject here)
   Namespace are then implicitely defined by where you code gets  
executed */
ParentObject := Object clone do(
        myMethod1 := method(
                "Method located in parent" println
        )
        myMethod2 := method(
                call slotContext myMethod1 println
        )
        myMethod3 := method(
                self myMethod1 println
        )
)

childObject := ParentObject clone do(
        myMethod1 := method(
                "Method located in child" println
        )
}

childObject myMethod2 // prints "Method located in parent"
childObject myMethod3 // prints "Method located in child"

Can you support modifying method lookup/send based on the context in  
this way with libobjc_tr?
Some languages may decide that 'myMethod1 println' means 'call  
slotContext myMethod1 println' and self must be used explicitly to  
send a message to the receiver.

The idea behind slotContext is explained in details here: <>
As I explain it below I think what is detailed in the previous link  
can be seen in a less prototype-centric way.

The problem here is the support of both sender and slotContext.  
Personally I find this terminology a bit confusing. May be we can talk  
of send context and receive context.
In a more general way, I think message lookup and dispatching based on  
the context should be supported. In this perspective, the context is  
the union of the send context and the receive context. It makes  
possible to change the behavior/state of an object depending on:
- the sender or where the sender is located
- where the receiver is located
This should allow to support any kind of messaging style (including  
those not yet invented
 well at least I hope ;-)).

The receive context can be implemented by an ivar in the root object  
of languages targeting the runtime. However the send context cannot be  
supported cleanly without the runtime help. A first approach is to  
pass the sender and supports slotContext by adding an ivar/slot on the  
root object in the language. But a better solution could be to have a  
context object argument that language may choose to use or not. Such  
context object could then be subclassed to package additional context  
infos. A call object like in Io could then be dynamically built from  
the invocation/message and this context object. It would support a  
protocol similar to:
- sendContext (aka sender)
- receiveContext (either the receiver or another object)
- callStack
- may be few other stuff

In summary, languages can uses the context argument to pass any infos  
they need in order to implement exotic message dispatching. Not sure  
it's really interesting but a language could also extend context  
object to make a difference between sendContext and sender. For  
example, sendContext could be a method and sender the object owning  
the method. Somewhat as if sendContext was a post office and sender  
the person who uses the post office to send a letter.

Here is an example of what you can do by taking in account the context:

/* Let's say the receiver is a file object. This method then tells  
whether the receiver can be read
   depending on both the receiver location and the sender location.  
Returned value can be
   different if you call this method from two objects, each one  
located in a distinct namespace/path. */
- (BOOL) isReadable
{
        /* path represents a namespace */
        if ([[receiveContext path] isEqual: @"/public"])
        {
                return YES;
        }
        else if ([[sendContext path] isEqual: @"/somewhere/admin"])
        {
                return YES;
        }
	else /* In all other cases, for example [[sendContext path] isEqual:  
@"/somewhere/normalUser"] */
        {
                return NO;
        }
}

Now here is my proposal for message sending, something along these  
lines giving you access to the context in both lookup and call:

#define MSG_SEND(ret, obj, context, sel_name, sel_types, ...)\
                do\
                {\
                        static SEL selector = lookup_typed_selector(sel_name, 
sel_types);\
                        struct objc_slot * slot = slot_lookup(object, context, 
foo_sel);\
                        CALL_SLOT(ret, slot, obj, context, selector, 
__VA_ARGS__);\
                } while(0)

If the problem I have outlined really exists, what do you think?

Cheers,
Quentin.