Re: Patches for GDL2

[David Ayers]

Stéphane Corthésy wrote:

> Hi,
>
> here are some other patches for GDL2 (I still have lots in stock!). 

Keep 'em coming.  (But weekends are a bad time for me, so expect answers 
on during the week in most cases.)

> In MacOS X 10.2, there are some classes (public or private) which 
> deserve to be used IMHO: NSClassDescription, NSFault (private, 
> undocumented) and NSFaultHandler (private, undocumented). Seems these 
> are (quite) straight ports from EOF, down to Foundation. 

NSClassDescription already gives a bit of a headache... Now that you 
have identified these other classes, it seems clear that, Apple is 
slowly extending (enriching/bloating depending on your view) Foundation 
to EOControl classes.  The fact that they are undocumented either means 
they just didn't get around to it, (I kind of doubt it, as it would have 
be a copy-n-paste a lot simpler that the implementation changes due to 
the changing class names) or that the aren't ready for production use yet.

This will most likely become a real issue for base/gdl2 in the future.  
Currently the only case where I know that we have really replaced an 
EOClass with NSClass is EONull/NSNull.  This class has very limited 
semantics and (as of recent patches) both can be used transparently.  
(This means that Source code should be able to do [NSNull null] [[NSNull 
alloc]init] [NSNull new] [EONull null] [[EONull alloc]init] [EONull new] 
and always recieve the exact same object.  This important because the 
pointer equality check is defined by the API as a sufficient test for 
EO/NSNull.  If we can't guarantee this, the we have a bug.

The NSClassDescription is an abstract class that has less but (from what 
I've seen so far) matching semantics with EOClassDescription  with the 
exception that all associated symbols (notifications, valadtion keys, 
...) also change thier prefix. The  base / Foundation implementation 
also uses it's own caches that a potential EOClassDescription superclass 
doesn't have access to.

I guess we should be expacting to see an EOF 4 soon from Apple, once 
this transition os complete.  Now I'm personally very reluctant to 
change GDL2, which has a declared mission to be WO 4.5 compatible, to 
follow this transition at this point in time.  It is undocumented and I 
doubt there is any project currently using it which is ready to be 
ported to GNUstep.  Please correct me if I'm wrong.  This is a real case 
in an instable API and I would rather we stabailze GDL2 targeted WO 4.5 
API than track undocumented transitioning to EOF 4.

> Until we have tests, I can't assure you that they all work fine, but 
> till now, in my examples, they seem to work reliably well.

I'm sorry, I'll try to prioritize the "integrated" "real use case" 
tests, so that we can have at least something usable soon.  I've been 
doing more of specific API tests sofar, and there are not really at a 
point that has any true meaning for stability, which is why I've been 
reluctant to commit them.

> Moreover, I can't make GDL2's EOFault work on OSX, because I miss the 
> implementation of -[NSInvocation returnFrame:] and -[NSInvocation 
> initWithArgframe:selector:] for faults. 

This is something we should look into by either providing categories for 
OS X or changing our EOFault implementation to use GSObjCRuntime 
feature.  I'll look into this next week.

> I've modified EOClassDescription, EOFault and EOFaultHandler classes 
> to subclass these classes, and to implement only missing methods, or 
> methods that need to be overloaded. I've used HAVE_NSCLASSDESCRIPTION, 
> HAVE_NSFAULT and HAVE_NSFAULTHANDLER macros. 

Eventhough base also has NSCLASSDESCRIPTION but we don't want to use it 
for GDL2.

> Code is a bit messy, due to all these #ifdef, but it works.

It makes reading the header rather difficult also.  I think once we 
really do a transition, we should cleanly dived the declarations, either 
within the file or even seperate files.

> I guess you could also use base's NSClassDescription implementation as 
> superclass of EOClassDescription, if it works fine; this would avoid 
> duplicating code and functionalities. 

I'm not woried about duplication functionality here.  EOClassDescription 
is used for GDL2 and tracks the semantice of WO 4.5 where 
NSClassDescription tracks OS X.  The implementations already differ 
(even if it's just the notifications and other exported keys).

> Changelog
> EOControl/EOClassDescription.h: use GDL2CONTROL_EXPORT instead of extern;

Thanks, I missed these some how.

> make use of global vars instead of their values; added some casts 

Will also look into doing this. Thanks!

Now if you feel strongly about using the undocumented classes (which I 
currently don't have access to, to see how they differ from WO 4.5 
semantics) please convince me.  Then we should come up with clean 
mechanism to support them without obscurring our headers and sources.

Cheers,
Dave