Re: Reporting errors from key-value-coding accessors
Re: Reporting errors from key-value-coding accessors
- Subject: Re: Reporting errors from key-value-coding accessors
- From: Dustin Voss <email@hidden>
- Date: Sun, 21 Aug 2005 18:40:08 -0700
On 20 Aug 2005, at 6:49 AM, Bill Cheeseman wrote:
on 2005-08-19 8:17 PM, Mark Alldritt at email@hidden
wrote:
1) For Cocoa Scripting, the best option is to use a parallel set of
Cocoa Scripting KVC accessors. This is usually necessary anyway, as
the semantics of scripted mutation/access can differ from UI or
internal mutation/access, and separate accessors are the only way to
enforce read-only properties (although you can mark a property as
read-only in the dictionary, Cocoa Scripting does not check that).
The parallel accessor just calls the primitive accessor and may also
perform validation using the validation methods.
[Th]e thought of maintaining all these parallel accessors is
daunting. In C++,
one would write templates to machine generate this kind of thing.
Is there
some Objective-C way of (a) generating all this code, and (b)
validating
that its all in-sync at compile time?
I think he was greatly overstating the need for parallel scripting
accessors, although it does strike me as a pretty clean way to do
it if you
keep your sources organized well (such as using a separate AppleScript
category file for the AppleScript accessors). I'm working on these
issues
now, and so far I seem to be able to put everything I need into a
single
getter -- though of course it becomes a bit more complex than one
is used
to, what with all the undo action naming and Core Data
paraphernalia that
ends up in the getter. Perhaps it's six of one and half a dozen of the
other.
Possibly I'm putting too much weight on parallel accessors. You can
certainly check to see if your getter is being called by AppleScript
by checking for a scripting command, as Bill mentions in another
reply. But if that command is unrelated and only calling the accessor
indirectly or as a side-effect, maybe you don't want to report a
script error. A way around this possibility is not only to check to
see if there is a scripting command, but also ensure that it is an
NSGetCommand or NSSetCommand. But I prefer the cleaner parallel
accessor approach.
And maintaining them might not be as hard as you think. There is a
central place where you can intervene. You can create a set of
"virtual" accessors that is the same key as a real accessor, except
with "AS" at the end. You can override setValueForKey: and
valueForKey: and adding special behavior if it sees such a key. You'd
strip off the "AS", call the superclass implementation, and then do
the special behavior you need.
If you add the class to the error-response chain, the special
behavior could include intercepting an NSError and turning it into a
scripting error, or something.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden