[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:
http://www.strongtalk.org/downloads/mixins-paper.ps
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).
David