On 24 Jun 2009, at 12:16, Niels Grewe wrote: >> You can eliminate the clang dependency with blocks by sending a - >> value: message to blocks. This means that it will work with >> Smalltalk >> blocks as well as Objective-C blocks (remember, blocks are objects >> too). This will let you compile the framework code with GCC but code >> using it with clang. > > I wasn't aware that the LanguageKit runtime was handling Objective-C > blocks as well. But I'm not sure how to move to using BlockClosure > objects instead of the ObjC2 block notation. I'm seeing two problems: > > * LanguageKit depends on EtoileFoundation, so without creating a > circular dependency, the higher-order messaging code could not live > there anymore. > * for -filterWithBlock: I'm as of yet expecting BOOLs, not objects, to > be returned by the closure. All the -value: methods seem to have id > as > their return type. I would intend to work around that by require > an NSValue/NSNumber to be returned from the closure and unbox it in > the filter code. Would that work with the Smalltalk implementation?
I see the problem. LanguageKit doesn't implement the Objective-C blocks, the Objective-C2 framework does, LanguageKit implements Smalltalk blocks. In the next release, EtoileFoundation will depend on the ObjectiveC2 framework. They should, however, have overlapping functionality. For things like map, you can just declare an informal protocol like this: @interface NSObject (Block) - (id)value:(id)value; @end Then just make the block an id and it will work. The predicate blocks are more complicated. Leave them as they are for now. I suspect that Apple will ignore this problem and not provide any Objective-C method for calling blocks that return something other than id or take something other than id as arguments. For now, ignore Smalltalk blocks. We can always add wrapper methods around this for Smalltalk blocks when we've come up with a good way of doing it. If clang provides sensible type encoding for blocks, we can possibly do something in LK to do the auto boxing differently... I've made a few (very minor) comments in the review system. Once these changes are made, I'm happy for it to go in. I don't think you have commit access yet; I think you need to request project membership on GNA, and then I can approve it. Trying to do it the other way around doesn't seem to be working. David _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
