Re: [F-Script-talk] adding Blocks as methods to ObjC classes

[Ken F. <ken...@gm...>]

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