On Mon, Feb 14, 2011 at 12:51 AM, Richard Frith-Macdonald <
rich...@tiptree.demon.co.uk> wrote:
> So, I've updated the NSNumberFormatter code to revert to the original
> instance variable layout and use the pointer to store the extra data.
> Please could you have a look at what I did for -copyWit
On 13 Feb 2011, at 22:13, Stefan Bidi wrote:
> 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 _
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
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 wrote:
>> Hi Stefan,
>>
>> I've not looked at the code in detail, but I thought you were creating a
>> private subclass for the old an
On 11 Feb 2011, at 23:50, Stefan Bidi wrote:
> On Fri, Feb 11, 2011 at 5:42 PM, David Chisnall 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 pri
On Fri, Feb 11, 2011 at 5:42 PM, David Chisnall 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 no
Hi Stefan,
On 11 Feb 2011, at 19:02, Stefan Bidi wrote:
> On Fri, Feb 11, 2011 at 9:15 AM, Richard Frith-Macdonald
> wrote:
>> 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 br
On Fri, Feb 11, 2011 at 9:15 AM, Richard Frith-Macdonald <
rich...@tiptree.demon.co.uk> wrote:
> 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 rele
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 w
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 we
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
I've just added an unused ivar for future expansion to NSRegularExpression.
If you're subclassing NSRegularExpression and not using the non-fragile ABI[1],
then you will need to recompile. This is done now, because NSRegularExpression
was not part of the last release, so it will only affect peo
12 matches
Mail list logo
