[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Chisnall
Subject: Re: [Etoile-dev] ANN: New Objective-C Runtime
Date: Sun, 11 Nov 2007 01:15:54 +0000

Hey Quentin,

On 11 Nov 2007, at 00:42, Quentin Mathé wrote:

As we already discussed it, I really like the whole design except the
fact protocols are only available at class level.

I tried to clarify this a bit in the blog posting. What I call 'classes' in the current runtime are closer to mixins in Animorphic Smalltalk; they can be viewed as mixins, categories, classes or concrete protocols, depending on what you are doing with them. A class is essentially just a mixin applied to the null class. You might like to take a look a this paper to see where my inspiration comes from:


I don't really want to move protocols down to the object layer because that would bloat the metaobject model - protocols are just syntactic sugar for method collections at the moment, just as classes are just sugar for factory objects.

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.

I'd be interested in seeing this.

I am not completely convinced by the Io question. I could easily add another parameter to the message lookup function at the moment, however any compiler producing code from Objective-C wouldn't know what to do with this (not that that's a significant problem - I've added other things to the runtime that are not used by Objective-C, but I'm not sure what the default should be. NULL? The sender's version of self?) I think I'd have to take a look at a lookup function for Io before I made a final decision. In your -isReadable example, it seems like -isReadable:(id)sender would give the same kind of behaviour. In principle, I really like the idea of getting a sender implicitly added, but in practice I think we don't gain much from having it as anything other than a parameter in the method itself. Methods that make use of this third argument will have to have different signatures to all Objective-C methods (we can't redefine IMP without breaking a lot of code).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]