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 _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
