I made the changes to NSNumberFormatter. Can someone take a look and make sure it's correct? I went a slightly different route and simply return the subclass (NSNumberFormatter10_4) all the time. I also used the padding ivar to hold the _behavior variable. That way both classes can use it.
I'm not sure I really like this, though. Wouldn't this break every instance where NSNumberFormatter gets subclassed since the default behavior is not what that subclass would expect? Can we make a note somewhere that whenever we break ABI in the future we go ahead and have all the 10.4+ code in NSNumberFormatter instead of a subclass? Stef On Sat, Feb 12, 2011 at 6:59 AM, Quentin Mathé <[email protected]> wrote: > Le 12 févr. 2011 à 09:11, Richard Frith-Macdonald a écrit : > > > On 11 Feb 2011, at 23:50, Stefan Bidi wrote: > > > >> On Fri, Feb 11, 2011 at 5:42 PM, David Chisnall <[email protected]> > wrote: > >> Hi Stefan, > >> > >> I've not looked at the code in detail, but I thought you were creating a > private subclass for the old and new behaviours - would it not be possible > to simply return a private subclass instance from the constructors and not > change the ivar layout of the superclass? > >> > >> I really haven't got a clue how to go about getting something like that > done. I'm still at the "getting my feet wet" stage of OOP + ObjC. I'll > have a look at how NSString and it's subclasses are implemented, but I'll > probably need someone holding my hand, at least part of the way. > > > > The idea of using a subclass sounds good, and it's quite easy. > > I wouldn't recommend looking at NSString as an example though ... that's > a much, much more complex case than would be needed. > > > > The simple subclassing solution would be to keep the old implementation > in the base class, and just modify the +allocWithZone: method. > > eg. > > > > + (id) allocWithZone: (NSZone*z) > > { > > if (using_new_api && [NSDateFormatter class] == self) > > { > > // If the subclass calls the super implementation, the check for the > class will prevent recursion. > > return [subclass allocWithZone: z]; > > } > > else > > { > > return [super allocWithZone: z]; > > } > > } > > The problem I see with this approach is that you can change the formatter > behavior at runtime with -setFormatterBehavior:. > > May be the class cluster approach is still a valid one, if it's possible to > use isa swizzling. e.g. Two subclasses NSDateFormatterBehavior10_0 and > NSDateFormatterBehavior10_4 with the same ivars (or instance size), and > -setFormatterBehavior implemented as below: > > -setFormatterBehavior: > { > // NOTE: I haven't taken in account the default behavior case. > if (behavior == NSDateFormatterBehavior10_0) > { > behaviorClass = [NSDateFormatterBehavior10_0 class]; > } > else if (behavior == NSDateFormatterBehavior10_4) > { > behaviorClass = [NSDateFormatterBehavior10_4 class]; > } > objc_setClass(self, behaviorClass); > } > > Cheers, > Quentin. > _______________________________________________ > Gnustep-dev mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/gnustep-dev >
_______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
