Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: Philippe Mougin <email@hidden>
- Date: Fri, 7 Jan 2005 19:29:31 +0100
Le 6 janv. 05, à 19:45, Charlton Wilbur a écrit :
On Jan 6, 2005, at 11:56 AM, Philippe Mougin wrote:
There is a flaw in you demonstration when you state that:
So our most recent example could also have been written:
foo.inputMessage("doSomethingWithAndWith", @list(bar, baz));
quux = foo.outputMessage("doSomethingWithAndWith");
which has a striking similarity to:
[foo.setValue: [NSArray arrayWithObjects: bar, baz, nil] forKey:
@"doSomethingWithAndWith"];
quux = [foo valueForKey: @"doSomethingWithAndWith"];
...and conclude that your language and KVC are equivalent.
The "striking similarity" you see is only at the very superficial
level of methods signatures. But you left out completely the
semantics of KVC, which are defined by the KVC documentation and
attach to the setValue:forKey: and valueForKey: methods a particular
behavior. Unfortunately, the semantics provided (or mandated) by KVC
cannot support the semantic of the language you describe, and
consequently your language cannot be considered as something
equivalent to KVC.
Why can't KVC support those semantics?
I've provided arguments for that, but if you don't find them
convincing, feel free to try to demonstrate that KVC can in fact
support those semantics, and show that to us. You will need to do that
in order for your demonstration to be complete.
Think about it: you are trying to demonstrate that the semantics of KVC
are at least as powerful as those of method invocation in general. You
claim to have demonstrated that, yet your demonstration does not
contain even the slightest reference to the actual *semantics* of KVC!
You demonstrate things about the semantics of KVC without taking them
into consideration at all! It should hints you that there is a problem
somewhere in your approach!
When Codd demonstrated that the relational algebra is at least as
powerful as the relational calculus, its did so by showing that an
arbitrary expression of the calculus can be reduced to a semantically
equivalent expression of the *algebra as defined by its particular
semantics*, and not to something that *superficially looked* like an
expression of the algebra but had other semantics.
Since your demonstration does not take at all into account the
semantics of KVC (again, there is absolutely no reference to them in
it), your demonstration has this funny property that it is independent
of those semantics. Consequently, in an alternative world where KVC
would use the same method signatures but where its semantics would be
defined, in the KVC documentation, to simply exit the program, or just
change the background picture, or send an email to Steve Jobs asking
him to remove DRM from the iTunes Music Store, your demonstration would
still apply unchanged and you could still claim that KVC is at least as
powerful as arbitrary method invocation (which, obviously, would be
wrong).
Well, using your example of result = [a isGreaterThan: b]; as an
example --
Assume that a and b are members of the same class, which has a private
instance variable called 'inputIsGreaterThan' and an accessor called
'number' that returns an NSNumber:
- (void) setIsGreaterThan: (id) input
{
inputIsGreaterThan = input;
}
- (id) isGreaterThan
{
return [[self number] compare: [inputIsGreaterThan number]] ==
NSOrderedAscending;
}
With this, you can *completely* emulate result = [a isGreaterThan: b]
with KVC calls:
[a setValue: b forKey: @"isGreaterThan"];
result = [a valueForKey: @"isGreaterThan"];
These are not KVC calls.
They have the same signature than KVC calls but the methods they
eventually invoke (i.e. setIsGreaterThan: and isGreaterThan) do not
follow the semantics mandated by KVC, which are to set or get a value
associated with a particular key.
Best,
Philippe Mougin
http://www.fscript.org
_______________________________________________
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
| References: | |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Philippe Mougin <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Charlton Wilbur <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Philippe Mougin <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Charlton Wilbur <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Philippe Mougin <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Charlton Wilbur <email@hidden>) |