[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Key-Value Operators on Array

From: David Ayers
Subject: Re: Key-Value Operators on Array
Date: Fri, 07 May 2004 21:57:12 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

Tom Hageman wrote:
Ach, I was a bit too trigger-happy on the Deliver button (and confused about which mailinglist it was being sent to, as you probably can tell :-/)

On Thu,  6 May 2004 23:59:52 +0200, I wrote:

Hi Philip,

On Thu, 6 May 2004 18:37:12 +0200, Philip Motteli wrote:


Usually, every key-value operation, that is applied to an array, is
applied to its contents. So the array is actually transparent.
There are certain exceptions though:


They are all marked by a preceding '@'. All these operators are sent
to> the array object itself and not to the objects it contains.

My question, proposal is: Why not use this '@' as a general mark, that
an operator should be sent to the array itself? Not restrict its use
to> these few mentionned predefined operators? This wouldn't be a
problem for code written for Cocoa. Cocoa would just> not have that
feature and (probably) raise an exception.

Or is there perhaps another way to do that and I'm just missing

In a previous incarnation (EOF) of key-value coding you could add
-compute<Name>ForKey: methods in a category of NSArray, and these would
be made available as "@<name>" operators in -valueForKeyPath:

For example, one could implement:

@interface NSArray(MyCategory)
- (id)computeAtForKey:(NSString *)aKey;

such that it can subsequently be used like:

secondElement = [anArray valueForKeyPath:@"@at.2"];


nameOfThirdElement = [anArray valueForKeyPath:@"@at.3.name"];

I haven't checked that if this mechanism still works in the Mac OS X
10.3 Cocoa incarnation though...

...or if it works at all in the GNUstep incarnation.

Well we have an implementation of this in GDL2. As we try to support both GNUstep and Cocoa but strive WO4.5 compatibility we may have issues if some of this is moved/copied to -base, but maybe not. (I'm preparing patches with which we have some control over Category precedence.) Would it be possible for you to include the "EOControl" part of GDL2? I guess it depends on whether current Foundation implements this. If it doesn't I'd rather not add that feature to base and advise people to use GDL2 if they need it. Yet if it does, I can try to transfer the implementation even though there are some details still to be discussed.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]