Re: Cocoa et al as HCI usability problem
Re: Cocoa et al as HCI usability problem
- Subject: Re: Cocoa et al as HCI usability problem
- From: Jean-Daniel Dupas <email@hidden>
- Date: Mon, 19 May 2008 23:20:12 +0200
Le 19 mai 08 à 22:36, Peter Duniho a écrit :
Date: Mon, 19 May 2008 20:31:02 +0200
From: Andreas Mayer <email@hidden>
This is (part of) a method that handles an AppleScript command send
to
the application.
One possible argument is the color to be used for display:
- (id)handleDisplayCommand:(NSScriptCommand *)command
{
NSDictionary *args = [command evaluatedArguments];
NSString *colorName = [args objectForKey:@"color"];
NSColor *color;
...
if (colorName) {
SEL colorSelector = NSSelectorFromString([colorName
stringByAppendingString:@"Color"]);
if ([[NSColor class] respondsToSelector:colorSelector]) {
color = objc_msgSend([NSColor class], colorSelector);
}
}
...
}
This way you may use any color name that NSColor supports.
In .NET, you'd just call Color.FromName().
More generally, as before, any code that is simply checking
"respondsToSelector" and then calling the specific selector, that
can easily be implemented in C# or Java using reflection (assuming
there's not a better, more idiomatic approach in those languages, as
often there would be). And situations when one would need this are
generally far and few between (i.e. not common enough to dictate an
entire language paradigm), especially when a class has the foresight
to implement that kind of functionality already.
I appreciate the example. It's certainly reasonably elegant and to
the point, and it's more "real world" than some of the other ones
(bridging Cocoa to another language? yeah, right...a) it's not like
you can't interface between languages with other languages, and b)
this is not the kind of thing one is going to see in general
application code). But not the sort of compelling "we really need
the language to be this way otherwise it just doesn't work" example
I was hoping for.
Thanks,
Pete
And as we are here, note also that Key-Value-Coding uses dynamic
properties of the language.
OK, implementing valueForKey: and setValue:forKey: is probably easy
using introspection.
So now, have a look at KVO and bindings. You can add an observer to
any model object (even to object that was compile before KVO was
implemented) and when any accessor is call on this model object, the
observer will receive a notification.
How it works ? Easy, when you register an observer, the Cocoa
framework dynamically create a proxy class, and dynamically change the
type of your model object into this proxy class, so any call perform
on your model will now be caugth by this proxy. Note that the runtime
does not create a new instance, it really change the type of the
instance you're using (that's dynamic typing).
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden