gnustep-dev
[Top][All Lists]
Advanced

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

Re: Heads Up: ABI Change


From: Stefan Bidi
Subject: Re: Heads Up: ABI Change
Date: Sun, 13 Feb 2011 16:13:29 -0600

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é <address@hidden> 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 <address@hidden> 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
address@hidden
http://lists.gnu.org/mailman/listinfo/gnustep-dev


reply via email to

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