[bug #22565] EOKeyValueCoding: Support modern Cocoa KVC semantics for NSArray aggregate functions

[Tim McIntosh]

Follow-up Comment #6, bug #22565 (project gnustep):

I agree that it looks like that's what Apple did.  It appears that in Cocoa's
NSArray, valueForKeyPath: only interprets multi-component key paths starting
with "@" as aggregate functions, and valueForKey: only interprets keys
starting with "@" to mean that [super valueForKey:] should be invoked with the
key following the "@".

For example, this works in Cocoa (10.5):
  [array valueForKeyPath: @"@sum.property"]
  [array valueForKey: @"@lastObject"]
  [array valueForKeyPath: @"@lastObject"]
but this does not:
  [array valueForKey: @"@sum.property"];
  [array valueForKeyPath: @"@lastObject.locations"]

It appears that in EOF's NSArray additions, valueForKeyPath: just treats a
path starting with "@" a single key, passing it to valueForKey:, which invokes
the appropriate computeXyzForKey: method with the key path following the
aggregate function.  The computeXyzForKey: method then uses valueForKeyPath:,
as in my original patch.

This appears to be true for EOF 2.1 and WO/EOF 4.0.1, anyway (I just ran the
attached sample code on 4.0.1 and got the same results as EOF 2.1 (see
KVC.m)).  I suspect that it is also true for WO 4.5.

David, can you verify how it works with WO 4.5?

Thus, it appears that I don't really need the new Cocoa behavior after all--I
just need the old EOF-compatible behavior.

I've attached a refinement of my original patch to EOKeyValueCoding.m, which
I believe brings GDL2's behavior into alignment with EOF:
- Removed special case for "count" and "@count" keys.
- Changed valueForKeyPath: to treat paths beginning with "@" as a single
key.
- Change valueForKey: to valueForKeyPath: in computeXyzForKey: methods.
- Updates comments.

For now, it seems like it would be best to keep the GDL2 and -base
implementations separate.  -base can implement the Cocoa behavior and GDL2 can
implement the EOF behavior.  GDL2 still needs to override Cocoa's methods in
order to provide the WO4.5 behavior when running on Cocoa, anyway.

It seems like GDL2's [NSArray valueForKey:] behavior (after patching) could
easily be made compatible with Cocoa's by just falling back to [super
valueForKey:] if no suitable computeXyzForKey: method is found for a key
starting with "@".  It seems like this would be more elegant than Cocoa's
implementation.

What do you guys think?  Am I missing anything here?


(file #15272)
    _______________________________________________________

Additional Item Attachment:

File name: EOKeyValueCoding.m-2.patch     Size:6 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22565>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/