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.
Cheers,
Dave
_______________________________________________
Gnustep-dev mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/gnustep-dev