Re: GDL2 patches (2)

[David Ayers]

Stéphane Corthésy wrote:

> Some more patches for GDL2.
>
> Stéphane
>
> Changelog
>
> EOControl/EOControl.h: added inclusion of EODefines.h and 
> EOArrayDataSource.h 

Thanks, I guess I lost the version that included EOArrayDataSource.h!  
I'm reluctant to include EODefines.h.  All headers that need it should 
inlcude it explicitly.  Including it here may hide the missing 
inclusions.  (Eventhough, once it is included it won't expose any 
missing inclusions there after.)

> EOControl/EOEditingContext.m: declared 
> +[EOEditingContext(EOEditingContextPrivate) 
> _observeUndoManagerNotifications] to avoid compiler warning 

Thanks, I'll add a couple of other declarations to quiet down compiler.

> EOControl/EONSAddOns.m: added cast to avoid compiler warning 

This warning must be OS X' gcc specific, but thanks.

> EOControl/EOOrQualifier.m: replaced use of autoreleased object by 
> RETAIN/RELEASE

I would rather use consistent object management.  Let's postpone these 
conversions.  In fact I'm hoping to reimplement this method with the use 
of a:
return AUTORELEASE([[NSArray alloc] initWithObject:qualifiers 
varArgList: ap]);
That I would like included on GSCategories... (Richard ? Pretty 
please... ;-) )

> EOControl/EOSortOrdering.h: corrected bug: EOSortOrderingComparison 
> category must be implemented on NSNull, not EONull, because EONull 
> class never instantiates EONull instances, it always returns the 
> NSNull instance
> EOControl/EOSortOrdering.m: ditto 

It's not a bug, it's feature... Notice the #define EONull NSNull in the 
implementation file :-)

As most code #including the header will want EONull to implement the 
methods, but we are internally using NSNull, the switch is done only in 
the implementation file.  But maybe we should move the define closer to 
the category implementation.  Or be explicit about it in the 
implementation file and change the name in the implementation 
definition.  Or maybe move the define to EONull.h.  I'm not sure which 
approach is less confusing.

This is one of the main reasons, I don't want to introduce this 
ambiguity for EO/NSClassDescription and the other undocumented EOControl 
classes that seem to have found thier way into Foundation.

Cheers.
Dave