RFC: GDL2 differences to EOF / WO4.5.1

[David Ayers]

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
- EOModel does not implement isEqual:
...
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.

Along with that comes a function (probably in EONSAndOns (and utility 
class for thread safe access to global locks for GDL2))
BOOL
GSUseStrictWO451Compatiblity(NSString *key)
which caches the result from the default evaluation.  I'm not intending 
to update the cache.  What ever the default is when it's read, that will 
determine the behaviour of that process.

When set to YES, it would:
- ignore the special handling of quoted keys in GDL2 KVC
- evaluate [[EONull null] compareAscending: nil] to NSOrderedAscending 
(instead of NSOrderedSame as we do now.)
- have [EOModel isEqual:] call super instead of a sane isEqual: 
implementation, that I would like to have a look at later.

Currently I'm basing all my tests on *exact* WO4.5.1 compatibility, so 
that they could be verified on WO4.5.1, if someone gets them running on 
that system at some point in time (after I finally put them on CVS :-) ).

I've added the parameter to the function so that maybe the user can fine 
tune the behaviour later with more defaults like:
GSWO451CompatibleEOKeyValueCoding
GSWO451CompatibleEOSortOrdering
GSWO451CompatibleEOModel
But I'm not sure whether this is such a good idea and I won't use it 
until someone comes up with the need for it.

What do you think?

Cheers,
Dave