|
From: | David Ayers |
Subject: | Re: GDL2 - patches for OSX (1) |
Date: | Wed, 26 Mar 2003 23:11:08 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 |
Stéphane Corthésy wrote:
EOControl/EODeprecated.h: new file declaring some deprecated methods/classes/symbols; methods/classes/symbols are still implemented but should no longer be used; they are no longer declared in their respective header files. Hmm. ok we should have the file but as those methods are not really depricated for WO4.5, in fact we'll have to look in from where they came. I think we should create the file an insert those things that were depricated for WO4.5 (EOUndoManager, NSObject -flushClassKeyBindings, EOClassDescription delegate handling and the hint keys. If you know what the depricated methods do and supply an implementation (I guess I'll create EODepricated.m file for the above anyway) then we could consider including them.In fact, only declaration of methods/symbols has been moved to EODeprecated.h, as mentioned: implementation is still in the old location. No need to create a EODeprecated.m file.
Yes, I figured that, but I was thinking of putting those implementations into this file, which were not part of WO4.5 to keep them out of the orignal file... but you are probably right, make the changes in the original file (maybe in categories with a name identifying them to be no WO4.5 for now.
diff -r1.4 EOControl.h > #import <EOControl/EOKeyValueCodingBase.h> Why do you need this? I'm looking at obsoleting this file (and it's *.m counterpart). I use only that part in .m: #if FOUNDATION_HAS_KVC // That's strange: there are no constants defined for these values, // neither in GNUStep's nor in Apple's Foundation NSString *EOUnknownKeyException = @"NSUnknownKeyException"; NSString *EOTargetObjectUserInfoKey = @"NSTargetObjectUserInfoKey"; NSString *EOUnknownUserInfoKey = @"NSUnknownUserInfoKey";#endif
Thanks, we should move these to another file then, I believe.
As on OSX we use Apple's implementation of KVC, we should refer to the same values for the exceptions in KVC.
Well actually we currently do (as of your patch) but will alter it (once I've got my patch in). There are subtle differences, which will be documented in the code. I haven't checked in detail, how these keys my differ (in content). We might end up setting values for mutliple namespaces. But I'm not quite there yet... and until then.
Thanks, Dave
[Prev in Thread] | Current Thread | [Next in Thread] |