gnustep-dev
[Top][All Lists]
Advanced

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

Re: fyi - Mac OS native GDL2 / GSWeb Installer package


From: David Ayers
Subject: Re: fyi - Mac OS native GDL2 / GSWeb Installer package
Date: Tue, 11 Mar 2008 20:02:51 +0100
User-agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080110)

Hello Tim.

just a quick status report...

Tim McIntosh schrieb:

> I think I was being too vague with regard to KVC.  I wasn't referring to
> the deprecated KVC methods issue that has been discussed on the list
> recently, but something much more trivial.  All I was talking about was
> the difference in behavior of -[NSDictionary valueForKey:] and
> -[NSDictionary storedValueForKey:] with respect to "special keys"
> (GDL2's @"allKeys" vs. Cocoa's @"@allKeys"),  and the different handling
> of NSArray aggregate functions when there is a key path following the
> aggregating operator instead of a simple key.
> 
> For example:   address@hidden@count
> 
> With Cocoa's -[NSArray valueForKeyPath:] behavior, this would invoke
> [object valueForKeyPath: @"address@hidden"] on each object in the
> display group, then return the sum of the counts.

This definitely doesn't work with WO45, but I think it is a natural
extension of its concepts.  So I'm inclined to attempt to support it.

The funny thing is, that I think we already could do this if NSObject's
valueForKeyPath: would invoke valueForKeyPath: on the result of the
valueForKey: of the first component with the remaining key path instead
of calling valueForKey: with each component.

Yet this is currently just a theory and I suppose you were having issues
on Cocoa's Foundation? And I'd hate to have to override valueForKeyPath:
on Cocoa...

> With GDL2's behavior, this would attempt to invoke [[object valueForKey:
> @"itemsArray"] decimalValue] on each object in the display group, sum
> the results, and then invoke [result valueForKey: @"@count"] on the
> sum--none of which would actually work as intended in this case.

Actually I'm not sure I get this far yet with -base.  But it's something
I think we could handle.

> My KVC changes are really pretty simple/naive (see attached patch).  I
> was assuming this was an EOF vs. Cocoa behavior difference, but I'm not
> really sure about that.  The old EOF documentation that I looked at
> didn't seem to be clear on what the behavior should be in this case, and
> I didn't have a setup where I could test EOF to see what it does,
> compared to GDL2.  I don't have a high degree of confidence that I'm
> doing "the right thing" here, but I was trying to get a specific
> application working without changing any of its logic, and this seemed
> to do the trick.

Yeah... this patch is a bit of a hammer.  And like I said, I'd like to
see your example work for GDL2 proper and I think it can... but it may
take a bit.

I think this deserves a feature request bug report.  Maybe you could
open one (assign it to gdl2 and me if that's possible).  Possibly attach
you patch also.

Oh... and in case you plan in providing more non-trivial patches to GDL2
you should start considering a copyright assignment.

Cheers,
David




reply via email to

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