[Top][All Lists]

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

Re: RFC: GDL2 differences to EOF / WO4.5.1

From: Giulio Cesare Solaroli
Subject: Re: RFC: GDL2 differences to EOF / WO4.5.1
Date: Wed, 26 Mar 2003 17:25:24 +0100

Hi everybody,

it has been a while since I haven't been able to read this list, but I am very happy to see to see such progress on GDL2. I don't know if anybody is interested, but a long time ago we did release a library, called IBNDBTestingKit, that extends OCUnit to provide a suitable environment for automatic, EOF related, tests.

At the moment the library is "Out of order" as the OracleEOAdaptor for Jaguar (the configuration we are using with WO 4.5.1) did break it and we have never found the time to find and solve this problem.

If anybody is interested in this and a few other frameworks, we would be very pleased to give them to the GSWeb project. An old snapshot of the frameworks is available at, but we can also provide an updated version upon request.

Giulio Cesare Solaroli

On Wednesday, Mar 12, 2003, at 22:37 Europe/Rome, David Ayers wrote:

Manuel Guesdon wrote:

Hi David,

On Wed, 12 Mar 2003 18:23:18 +0100 David Ayers <address@hidden> wrote:

>| Hello Manuel,
>| >| I'm coming up with oddities of EOF 3.0 of WO4.5.1 and subtle differences >| to GDL2 here and there: >| - EONull compareAscending: nil returns NSOrderedAscending instead of >| NSOrderedSame

I have no specific preference.
I think GDL2 behaviour is correct so I would like keep it.

>| - EOModel does not implement isEqual:

And WO4.5 does ? So we'll  to implement it...

No it doesn't, but I think GDL2 should anyway. (It's rather trivial, but it changes behaviour.)

>| And I haven't gotten far enough into .gswd/.wod-parsing to analyse the >| GDL2 feature of NSDictionary valueForKeyPath and quoted key names. I >| would like to propose the following default: >| GSUseStrictWO451Compatiblity or GSUseStrictEOF451Compatiblity or >| GSUseStrictEOF30?Compatiblity or what ever better name someone comes up >| with.

I don't like too much this kind of things because if you use 2 frameworks or libraries which set a different behaviour, the result is unknown and may depend on some calling order. I still don't see real problem with quoted key names but if you want to make have a parameter to control this, I'm OK :-)

Well the point is that as soon as I continue to fine tune the tests, more and more of these issues will arise, and I wanted to put a general mechanism in place, which I could consistently use. But I do recognize your concerns...

For this one, we could act as WO4.5 anyway.

We could, I guess... (eventhough I still think current GDL2 behavior is better.)

>| - have [EOModel isEqual:] call super instead of a sane isEqual: >| implementation, that I would like to have a look at later.

For this one, WO4.5 implementation should be OK, shouldn't it ?

Actually it was during writing testcases that I noticed that it wasn't implemented. And it's not implemented in WO4.5 either. I just think we should.

Testing OS 4.2 vs WO 4.5 show some substantual differences in KVC of NSDictionary when was looking into GDL2 quoted key feature. I know that many of these are edge cases and subtle differences that cause no immediate harm in 98% of the usages. But in my experience, it's these 2% edge cases which makeup an unproportional amount of the debugging effort, especially when porting. This was my original concern.

On the other hand it is doubtful that all edge cases can be identitfied, no matter how estensive the tests are. And I may end up adding a lot of extensive edge case handling and still miss the ones that are causing problems. I also mean to keep and add comprehensive features, that are not part of EOF, and these might also trigger such problems.

In retrospect, I'm thinking of holding the default back for now and leaving GDL2 behaviour as it is in these edge conditions and comment code and test cases. I'll sleep over it again. Comments appreciated.


Gnustep-dev mailing list

reply via email to

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