Re: [F-Script-talk] adding Blocks as methods to ObjC classes
Brought to you by:
pmougin
From: Ken F. <ken...@gm...> - 2005-02-16 10:53:54
|
On Wed, 16 Feb 2005 01:54:42 -0700, Luke Nihlen <l_n...@ya...> wrote: > Ken, > > Thanks for the detailed response! I'd like to peruse your code, > unfortunately I don't have permissions to access the zip file at the > link you provided. Huh. As far as I can tell the link (and permissions) are fine, so maybe try it again? http://homepage.mac.com/kenferry/Software/KFDecorator/KFDecorator.zip > Since my methods are actually ObjC methods on a class I am hoping > F-Script wraps arguments for me. I have interest in writing type > conversion for the return, but haven't needed to yet since id is a > pretty useful return type for most purposes. The way I did it I needed to explicitly convert plain c arguments to objects, but you may have tapped into FScript's conversion stuff more directly than I did. > > When adding a block for a method not implemented by the base, all > > arguments and returns are assumed to be objects. There is a > > -[KFDecorator setBlock:forSelector:withSignature:] method for when > > that assumption isn't going to hold. > > > ah, is that an NSMethodSignature? Yep. They're a pain to create with documented methods, but there's an undocumented +[NSMethodSignature signatureWithObjCTypes:] that makes it pretty straightforward. The argument is a string of the sort you were talking about (e.g. "i@:@" means returns int, takes id, SEL, id as arguments). Your tack of taking a types string directly is a good idea. I'll change that. > > (1) You cannot set a block for a method implemented by KFDecorator > > itself, and KFDecorator is a subclass of NSObject as opposed to > > NSProxy. This is because I haven't worked around NSProxy's lack of a > > useful -[NSProxy methodSignatureForSelector:]. > > > > I wrote a working version of -methodSignatureForSelector by looking at > the F-Script code, maybe you can model one for NSProxy off of what I > wrote. I'll check it out. :-) > > (2) Since it's just a wrapper for a base object, you can only catch > > messages when you interject the decorator between a calling object and > > the base. That can be a good thing or a bad thing in different > > situations. > > > are you using forwardInvocation? Why do you have this limitation? Because I'm using forwardInvocation in the decorator (wrapper) object. If the base object sends a message to itself then the wrapper never sees it. > I am grooming my code to share, plus should have a usable server up in > a few days (just moved) so I'll let you know when there's a zip > available for DL. Looking forward to it. Cheers, Ken |