On 10 Feb 2011, at 14:14, Stefan Bidi wrote: > Hmm, I guess I should mentioned I messed around with the NSDateFormatter and > NSNumberFormatter ivars, as well. In order to support OS X 10.4+ methods I > had to add about 4-5 extra ivars to each of those classes. Seeing as I did > this a few weeks back and haven't heard any complaints, I assume it's all > good.
No ... this sort of stuff rarely actually breaks anything (how often does anyone want to subclass these things) but we have a 'contract' with our uses not to break ABI compatibility for stable releases (except very rarely on a major release). I would really like to be able to make a new minor stable release (so distributions can adopt it quickly without worrying about backward compatibility) by copying from svn trunk. So really we want to make sure that there are no changes in the size of the ivars of existing classes. This means that either we need to modify things so we are not using any new ivars in NSDateFormatter and NSNumberFormatter, or our next stable release really can't contain the latest implementation for these two classes. The 'padding' instance variable in each class definition is there precisely so that we can set gs_unused to be a pointer to extra data if we need to add instance variables without breaking the ABI. > NSCalendar does not have the padding ivar, do we want to add that in at some > point before the next release? Yes. _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev