Re: fyi - Mac OS native GDL2 / GSWeb Installer package
On Mar 11, 2008, at 2:02 PM, David Ayers wrote: 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: [EMAIL PROTECTED]@count With Cocoa's -[NSArray valueForKeyPath:] behavior, this would invoke [object valueForKeyPath: @[EMAIL PROTECTED]] 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. Seems that way to me, but it sounds like -base is just following the Apple documentation, which says: The default implementation gets the destination object for each relationship using valueForKey: and returns the result of a valueForKey: message to the final object. Yet this is currently just a theory and I suppose you were having issues on Cocoa's Foundation? From the above, it sounds like Cocoa's NSObject works the same as - base, but I didn't test it. Note: On Cocoa, I think it worked to just eliminate -valueForKeyPath: entirely from EOKeyValueCoding.m for this specific example, since Cocoa's NSArray implements a fixed set of operators, which includes the @sum and @count operators (see http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/ArrayOperators.html) . However, since Cocoa does not implement the generalized/extensible behavior as found in EOF, I figured it would be better to stick with the implementation in EOKeyValueCoding if it could be made to provide a superset of what Cocoa supports. 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. I'm not sure how far it was actually making it. I thought I was crashing on the -decimalValue message being sent to an array, but it's been too long since I actually debugged it to remember for sure. 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. https://savannah.gnu.org/bugs/index.php?22565 (Didn't see where I could assign you but I added you for e-mail notifications.) -Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: fyi - Mac OS native GDL2 / GSWeb Installer package
On Mar 11, 2008, at 3:11 PM, David Ayers wrote: David Ayers schrieb: Tim McIntosh schrieb: For example: [EMAIL PROTECTED]@count With Cocoa's -[NSArray valueForKeyPath:] behavior, this would invoke [object valueForKeyPath: @[EMAIL PROTECTED]] on each object in the display group, then return the sum of the counts. Actually, since Cocoa currently supports the aggregate keys, then maybe we need to move some of GDL2 KVC to -base... and then also -base's KVC would need more context with valueForKeyPath: on NSArray http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Protocols/NSKeyValueCoding_Protocol/Reference/Reference.html [http://tinyurl.com/2cq4rg] I should've read this before responding to the previous message. ;) Yes, Cocoa supports the aggregate keys, though it's approach is apparently not extensible like the EOF design. Would it make sense to treat this as a GNUstep extension and implement it in the -base Additions? That way you would still override the Cocoa implementation on Mac OS and maintain the ability to extend the set of aggregate keys. -Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: fyi - Mac OS native GDL2 / GSWeb Installer package
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: [EMAIL PROTECTED]@count With Cocoa's -[NSArray valueForKeyPath:] behavior, this would invoke [object valueForKeyPath: @[EMAIL PROTECTED]] 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: fyi - Mac OS native GDL2 / GSWeb Installer package
David Ayers schrieb: Tim McIntosh schrieb: For example: [EMAIL PROTECTED]@count With Cocoa's -[NSArray valueForKeyPath:] behavior, this would invoke [object valueForKeyPath: @[EMAIL PROTECTED]] on each object in the display group, then return the sum of the counts. Actually, since Cocoa currently supports the aggregate keys, then maybe we need to move some of GDL2 KVC to -base... and then also -base's KVC would need more context with valueForKeyPath: on NSArray http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Protocols/NSKeyValueCoding_Protocol/Reference/Reference.html [http://tinyurl.com/2cq4rg] Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: fyi - Mac OS native GDL2 / GSWeb Installer package
Hello Tim, Tim McIntosh schrieb: I've been working on a Mac OS native port of the GSWeb and GDL2 frameworks, for use with Xcode and the Cocoa frameworks outside of a full GNUstep environment. I have put together Installer packages for Mac OS 10.4 and 10.5, which can be found here: http://hoth.radiofreeomaha.net:3000/~tmcintos/GNUstepWeb/ Since I don't have OS X, I can't test it. I have made a number of minor changes that I eventually intend to either undo or get accepted into the mainline. One difference in this version that may never make it into the mainline is the use of Cocoa-style (native) KVC (as opposed to WO-4.5 style), which I wanted for use with the WO5 app that I'm porting. It depends on how well we can emulate compatibility. Currently GSWeb/GDL2 is used for Projects that are currently still deployed as GNUstep based and WO45 based applications. So it's very important not to break WO45 compatibility. Yet if we can emulate it in a similar way as -base is currently trying, then I'd take the patches as long as they don't show issues. Do you really need to change the internal KVC? Maybe we just need to implement a few more legacy methods in EOKeyValueCoding.m to get it work on OS X. (And avoid some warnings from -base while we are at it.) Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: fyi - Mac OS native GDL2 / GSWeb Installer package
Hi David, On Mar 6, 2008, at 7:54 AM, David Ayers wrote: Tim McIntosh schrieb: I have made a number of minor changes that I eventually intend to either undo or get accepted into the mainline. One difference in this version that may never make it into the mainline is the use of Cocoa-style (native) KVC (as opposed to WO-4.5 style), which I wanted for use with the WO5 app that I'm porting. It depends on how well we can emulate compatibility. Currently GSWeb/GDL2 is used for Projects that are currently still deployed as GNUstep based and WO45 based applications. So it's very important not to break WO45 compatibility. Yet if we can emulate it in a similar way as -base is currently trying, then I'd take the patches as long as they don't show issues. Sounds good. Do you really need to change the internal KVC? Maybe we just need to implement a few more legacy methods in EOKeyValueCoding.m to get it work on OS X. (And avoid some warnings from -base while we are at it.) 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: [EMAIL PROTECTED]@count With Cocoa's -[NSArray valueForKeyPath:] behavior, this would invoke [object valueForKeyPath: @[EMAIL PROTECTED]] on each object in the display group, then return the sum of the counts. 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. 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. Thanks for your help, Tim EOKeyValueCoding.m.diff Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
