Re: Return Code Dilemma
Re: Return Code Dilemma
- Subject: Re: Return Code Dilemma
- From: Allan Odgaard <email@hidden>
- Date: Fri, 30 Apr 2004 10:22:58 +0200
On 30. Apr 2004, at 1:24, Louis C. Sacha wrote:
[...] I'd like to have the class method return integer codes [...]
how might each of you gather this information that will become
available at an unknown time after the class method is called?
1) using Notifications to return the result [...]
2) Have the calling object provide a target and callback selector [...]
This is similar to option 1, but I use KVO for this. E.g.
@interface Worker : NSObject { NSString* result; }
@end
@implementation Worker
- (void)didFinishLengthyTask:(NSString*)theResult
{
[self setValue:theResult forKey:@"result"];
}
@end
What we have here is a Worker object where others can observe the
'result' key. I then write the 'consumer' class to be ignorant about
Worker, but gives it e.g. a "setDelayedResult:" method, and ehm...
through unsanctioned (!) use of bind:toObject:withKeyPath:options: we
can now connect the result of Worker so that each time 'result' is
changed, it will call setDelayedResult: with the new value as argument.
The advantages are IMHO that we have slightly less code in Worker (i.e.
no storing of callback receivers or broadcasting of notifications) and
certainly less code in the consumer, as it does not need to register
for notifications or callbacks, which also means that the consumer is
completely unaware of the Worker class, and the (in this case)
'delayedResult' could actually come from a dozen different places.
It's basically the same as with normal View/Controller and
Controller/Model bindings, I just use it between all sorts of objects
(and ignore that my programs may break if the default implementation of
bind:... is changed ;) ) -- effectively my "controller layer" is just a
set of bind:... statements which connect the objects the way I want
them to cooperate (and thus no actual objects with actual code!).
The flexibility here is IMO large -- imagine for example that 'result'
is actually a file path, and we wish to display the last path component
as the window title, we could just execute this single line in
didLoadWindow: or similar (where I setup "the logic"):
[window bind:@"title"
toObject:workerInstance
withKeyPath:@"result.lastPathComponent"
options:nil];
When 'result' change in workerInstance, it will automatically call
setTitle: on the window with the lastPathComponent sub-path of the
string (which translate to calling lastPathComponent on the string).
But if I haven't stressed it enough, I am making unjustified
assumptions about the binding system, and Scott will probably be all
over this post ;)
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.