gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: Removal of old (deprecated) template classes.


From: Fred Kiefer
Subject: Re: RFC: Removal of old (deprecated) template classes.
Date: Sun, 21 Nov 2004 17:49:43 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114

Gregory John Casamento wrote:
I am going to remove the templates in GSNibCompatibility.[hm].   These
templates are old and some of them don't work correctly (this is why they were
deprecated in the first place).  Their functionality has been entirely
superceded by the new template classes in GSNibTemplates.

First, a small explaination of what templates do.   They allow the user to, in
Gorm, select a custom class associated with a real class (such as a window or a
table, or any other object or widget at all) and, when the .gorm is saved, the
template is saved instead of the real object (it in fact contains the real
object) by the NSArchiver.  This allows the template to morph the class into
the subclass which was specified by the user in Gorm when it is loaded into the
application which contains the custom class the user wanted to use.

The older templates need to be removed so that it will clear the way for the
MOSX templates (for compatibility with keyed MOSX nib files) some of which have
the same name as the deprecated ones in GNUstep.  Although the code there is
clearly marked as deprecated, Fred Keifer has modified the code for
NSWindowTemplate in the GSNibCompatibility files for this purpose.  My plan is
to remove the code which was used for loading these classes from a .gorm file
and move Fred's code to someplace else and ultimately remove the
GSNibCompatibility.h and .m files.


Removing the old templates is fine for me. But why remove the whole file? It could just be reused to store the new templates and helper classes needed for keyed decoding. That way the code I added could stay where it is. :-)

Under normal circumstances, I would simply remove this code, but as this change
has the potential (minimal) to impact some rather old applications that might
still use these old templates, so I thought it was important enough to bring up
here.   I, however, would like to reserve the right to make the final decision
regardless of the consensus.


This sounds a bit strange, Gregory. When there are valid objections to the removal than you cannot reserve the right to do it anyway. I don't think that such will show up, but if they do,we have to accept it. Otherwise why start a discussion at all?

I'm not going to do anything right away.  I just want to open the discussion at
this point.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]