Thanks for the confirmation, I wanted to double check because if it didn’t I’d
waste a lot of time…...
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators
> On Nov 30, 2015, at 5:18 AM, Dave wrote:
>
> I’m guessing it overrides it? Right?
Right. A category method is a normal method. It just isn’t declared in the same
@interface.
—Jens
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do
On 13 Mar 2013, at 09:24, Markus Spoettl wrote:
On 3/13/13 9:36 AM, Dave wrote:
On 12 Mar 2013, at 21:34, Graham Cox wrote:
On 13/03/2013, at 6:53 AM, Dave wrote:
If that is the case, then how do you signal to the compiler/
analyzer that you
are returning a retained object?
In genera
And run the thing under Instruments, which would undoubtedly have shown memory
usage spiking even with modest data sets.
— F
On 14 Mar 2013, at 5:40 AM, Jean-Daniel Dupas wrote:
> Le 14 mars 2013 à 11:12, Richard Heard a écrit :
>
>> Your logic is clearly flawed. This only seems to r
Le 14 mars 2013 à 11:12, Richard Heard a écrit :
> Your logic is clearly flawed. This only seems to replace occurrences of $
> with the word DOLLAR.
>
> Also, if you are dealing with large strings, you could always use one of the
> below idioms to reduce memory pressure.
>
>
> @autoreleasep
Your logic is clearly flawed. This only seems to replace occurrences of $ with
the word DOLLAR.
Also, if you are dealing with large strings, you could always use one of the
below idioms to reduce memory pressure.
@autoreleasepool { }
or
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] i
On 13 Mar 2013, at 09:24, Markus Spoettl wrote:
On 3/13/13 9:36 AM, Dave wrote:
On 12 Mar 2013, at 21:34, Graham Cox wrote:
On 13/03/2013, at 6:53 AM, Dave wrote:
If that is the case, then how do you signal to the compiler/
analyzer that you
are returning a retained object?
In genera
Moderator
I've had a number of complaints about this thread.
This thread has gone beyond all reasonable value and the behavior is not
acceptable.
Nobody has a requirement to read and answer questions. The questions have been
answered politely by posters who have a long history on the list of h
On 12 Mar 2013, at 21:25, Graham Cox wrote:
On 13/03/2013, at 2:41 AM, Dave wrote:
So, what is it? Wind up merchant or Moron?
I don't think there's any need for this. If I caused offence, it
was unintended (I sometimes have trouble anticipating how others
might receive statements I m
On 3/13/13 9:36 AM, Dave wrote:
On 12 Mar 2013, at 21:34, Graham Cox wrote:
On 13/03/2013, at 6:53 AM, Dave wrote:
If that is the case, then how do you signal to the compiler/analyzer that you
are returning a retained object?
In general you shouldn't return a retained object (unless it's
On 12 Mar 2013, at 21:34, Graham Cox wrote:
On 13/03/2013, at 6:53 AM, Dave wrote:
If that is the case, then how do you signal to the compiler/
analyzer that you are returning a retained object?
In general you shouldn't return a retained object (unless it's
temporarily retained and will
On 13/03/2013, at 6:53 AM, Dave wrote:
> If that is the case, then how do you signal to the compiler/analyzer that you
> are returning a retained object?
In general you shouldn't return a retained object (unless it's temporarily
retained and will be autoreleased of course). If you are routine
On 13/03/2013, at 2:41 AM, Dave wrote:
> So, what is it? Wind up merchant or Moron?
>
I don't think there's any need for this. If I caused offence, it was unintended
(I sometimes have trouble anticipating how others might receive statements I
make, that's just something I have to live with)
On 12 Mar 2013, at 19:38, Jean-Daniel Dupas wrote:
Le 12 mars 2013 à 20:15, Dave a écrit :
On 12 Mar 2013, at 18:50, Jens Alfke wrote:
On Mar 12, 2013, at 9:44 AM, John McCall wrote:
However, that wouldn't be an idiomatic implementation. The
usual expectation is that allocating met
Le 12 mars 2013 à 20:15, Dave a écrit :
>
> On 12 Mar 2013, at 18:50, Jens Alfke wrote:
>
>>
>> On Mar 12, 2013, at 9:44 AM, John McCall wrote:
>>
>>> However, that wouldn't be an idiomatic implementation. The usual
>>> expectation is that allocating methods, like +new methods, construct
On 12 Mar 2013, at 18:50, Jens Alfke wrote:
On Mar 12, 2013, at 9:44 AM, John McCall wrote:
However, that wouldn't be an idiomatic implementation. The usual
expectation is that allocating methods, like +new methods,
construct an object *of type self* (at least).
Are you just quibbling
On Mar 12, 2013, at 9:44 AM, John McCall wrote:
> However, that wouldn't be an idiomatic implementation. The usual expectation
> is that allocating methods, like +new methods, construct an object *of type
> self* (at least).
Are you just quibbling about the prefix “new-“? The specific method
On 12 Mar 2013, at 16:44, John McCall wrote:
There is exactly one difference between [[self superclass] newDict]
and [super newDict] here: the value of 'self'. (This assumes the
obvious behavior for +superclass, of course.)
[[self superclass] newDict] is exactly equivalent to [Subclass1
On Mar 12, 2013, at 12:31 AM, Dave wrote:
> On 11 Mar 2013, at 21:45, John McCall wrote:
>> On Mar 11, 2013, at 2:02 PM, Dave wrote:
>>> On 11 Mar 2013, at 20:53, John McCall wrote:
On Mar 11, 2013, at 1:33 PM, Dave wrote:
> On 11 Mar 2013, at 20:26, Mike Abdullah wrote:
>>>
>>
On 12 Mar 2013, at 13:37, Graham Cox wrote:
On 12/03/2013, at 11:45 PM, Dave wrote:
Except it doesn't do what the above does!
Yes it does.
Oh No it doesn't!
It creates a copy of read only dictionary and then modifies that. If
the underlying dictionary changes, you will not see th
On 12/03/2013, at 11:45 PM, Dave wrote:
> Except it doesn't do what the above does!
Yes it does.
>>
>> @implementation DF2
>> + (NSDictionary*) dictionary
>> {
>> NSMutableDictionary* md = [[super dictionary] mutableCopy];
>> // add extra items to md
>> return [md autorelease
Hi,
What I have works fine now, but to explain:
Basically I have just a Class definition, e.g.
Class theClass;
I can't instantiate the class (not that I'd consider that anyway),
because I have no idea what side effects calling the init method of
the class would be, it mi
On 12/03/2013, at 6:31 PM, Dave wrote:
> I don't think you understand the difference between class methods and
> instance methods.
Are you certain you do?
> Here is an example of what I mean:
Why not state you goals instead of give us a lump of incoherent code?
As far as I can see you don
On 11 Mar 2013, at 21:14, Mike Abdullah wrote:
if from an instance + Method I do:
[super someMethod], then surely it's an error because this isn't
an instance?
It *is* an instance. An instance of the *metaclass*. This is where
you're deep into the guts of Objective-C :)
H, I think
On 11 Mar 2013, at 21:45, John McCall wrote:
On Mar 11, 2013, at 2:02 PM, Dave wrote:
On 11 Mar 2013, at 20:53, John McCall wrote:
On Mar 11, 2013, at 1:33 PM, Dave wrote:
On 11 Mar 2013, at 20:26, Mike Abdullah wrote:
I had assumed (and I thought I'd done something like this
befor
On Mar 11, 2013, at 2:02 PM, Dave wrote:
>
> On 11 Mar 2013, at 20:53, John McCall wrote:
>
>> On Mar 11, 2013, at 1:33 PM, Dave wrote:
>>> On 11 Mar 2013, at 20:26, Mike Abdullah wrote:
>
> I had assumed (and I thought I'd done something like this before) that
> the:
>
>>>
On Mar 11, 2013, at 1:55 PM, Dave wrote:
> Not sure I understand:
>
> if from an Instance - Method, I do:
>
> [super someMehod];
>
> It calls -someMehod in the superclass.
>
> if from an instance + Method I do:
>
> [super someMethod], then surely it's an error because this isn't an instance?
On Mar 11, 2013, at 2:55 PM, Dave wrote:
> On 11 Mar 2013, at 20:50, Jens Alfke wrote:
>
>>
>> On Mar 11, 2013, at 1:33 PM, Dave wrote:
>>
>>> There isn't a
>>> -newDict
>>> method defined, so how come I didn't get a complier error?
>>
>> Because the receiver is a Class, so the method is +new
On Mon, Mar 11, 2013, at 01:55 PM, Dave wrote:
> Not sure I understand:
>
> if from an Instance - Method, I do:
>
> [super someMehod];
>
> It calls -someMehod in the superclass.
>
> if from an instance + Method I do:
>
> [super someMethod], then surely it's an error because this isn't an
>
On 11 Mar 2013, at 20:55, Dave wrote:
>
> On 11 Mar 2013, at 20:50, Jens Alfke wrote:
>
>>
>> On Mar 11, 2013, at 1:33 PM, Dave wrote:
>>
>>> There isn't a
>>> -newDict
>>> method defined, so how come I didn't get a complier error?
>>
>> Because the receiver is a Class, so the method is +n
On Mar 11, 2013, at 1:45 PM, Dave wrote:
>>> myDict = [[super class] newDict];
>>
>> This should be [super newDict].
>
>> -- Seth
>
>
> Surely that would call the Instance Method (and there isn't one), I think the
> correct code is:
>
> [[self superclass] newDict];
>
> as someone else all
On 11 Mar 2013, at 20:49, Dave wrote:
> On 11 Mar 2013, at 20:45, Mike Abdullah wrote:
>
> Confused now, I thought you meant +.
>
> There is no instance of the class to call [super newDict] on?
>
> There is no:
>
> -NewDict method, just +newDict.
>
> So, surely [super newDict] should error?
On Mar 11, 2013, at 1:45 PM, Dave wrote:
> On 11 Mar 2013, at 20:30, Seth Willits wrote:
>> On Mar 11, 2013, at 1:21 PM, Dave wrote:
>>
>>> +(NSMutableDictionary*) newDict
>>> {
>>> return [[NSMutableDictionary alloc] init];
>>> }
>>
>> (I hope you're using ARC otherwise this is a memory leak.)
On 11 Mar 2013, at 20:53, John McCall wrote:
On Mar 11, 2013, at 1:33 PM, Dave wrote:
On 11 Mar 2013, at 20:26, Mike Abdullah wrote:
I had assumed (and I thought I'd done something like this
before) that the:
myDict = [[super class] newDict];
statement would call newDict in BaseClass??
On 11 Mar 2013, at 20:50, Jens Alfke wrote:
On Mar 11, 2013, at 1:33 PM, Dave wrote:
There isn't a
-newDict
method defined, so how come I didn't get a complier error?
Because the receiver is a Class, so the method is +newDict, which
exists.
Not sure I understand:
if from an Instan
On Mar 11, 2013, at 1:33 PM, Dave wrote:
> On 11 Mar 2013, at 20:26, Mike Abdullah wrote:
>>>
>>> I had assumed (and I thought I'd done something like this before) that the:
>>>
>>> myDict = [[super class] newDict];
>>>
>>> statement would call newDict in BaseClass Instead it calls the vers
On 11 Mar 2013, at 20:45, Mike Abdullah wrote:
On 11 Mar 2013, at 20:33, Dave wrote:
On 11 Mar 2013, at 20:26, Mike Abdullah wrote:
I had assumed (and I thought I'd done something like this
before) that the:
myDict = [[super class] newDict];
statement would call newDict in BaseClass
On Mar 11, 2013, at 1:33 PM, Dave wrote:
> There isn't a
> -newDict
> method defined, so how come I didn't get a complier error?
Because the receiver is a Class, so the method is +newDict, which exists.
—Jens
___
Cocoa-dev mailing list (Cocoa-dev@li
On Mar 11, 2013, at 1:26 PM, Dave wrote:
> I had assumed (and I thought I'd done something like this before) that the:
> myDict = [[super class] newDict];
> statement would call newDict in BaseClass Instead it calls the version in
> NewClass and goes into an infinite loop!!
No, what you wa
On 11 Mar 2013, at 20:30, Seth Willits wrote:
On Mar 11, 2013, at 1:21 PM, Dave wrote:
+(NSMutableDictionary*) newDict
{
return [[NSMutableDictionary alloc] init];
}
(I hope you're using ARC otherwise this is a memory leak.)
Yes, but it's only an example so don't worry about that, and, a
On 11 Mar 2013, at 20:33, Dave wrote:
>
> On 11 Mar 2013, at 20:26, Mike Abdullah wrote:
>>>
>>> I had assumed (and I thought I'd done something like this before) that the:
>>>
>>> myDict = [[super class] newDict];
>>>
>>> statement would call newDict in BaseClass Instead it calls the ve
On Mar 11, 2013, at 1:30 PM, Seth Willits wrote:
> On Mar 11, 2013, at 1:21 PM, Dave wrote:
>
>> +(NSMutableDictionary*) newDict
>> {
>> return [[NSMutableDictionary alloc] init];
>> }
>
> (I hope you're using ARC otherwise this is a memory leak.)
A 'new' prefix is defined as returning an ow
On Mar 11, 2013, at 4:30 PM, Seth Willits wrote:
> On Mar 11, 2013, at 1:21 PM, Dave wrote:
>
>> +(NSMutableDictionary*) newDict
>> {
>> return [[NSMutableDictionary alloc] init];
>> }
>
> (I hope you're using ARC otherwise this is a memory leak.)
Not if the caller knows to observe the rule ab
On 11 Mar 2013, at 20:26, Mike Abdullah wrote:
I had assumed (and I thought I'd done something like this before)
that the:
myDict = [[super class] newDict];
statement would call newDict in BaseClass Instead it calls the
version in NewClass and goes into an infinite loop!!
Yes. [sup
On Mar 11, 2013, at 1:21 PM, Dave wrote:
> +(NSMutableDictionary*) newDict
> {
> return [[NSMutableDictionary alloc] init];
> }
(I hope you're using ARC otherwise this is a memory leak.)
> myDict = [[super class] newDict];
This should be [super newDict].
-- Seth
_
On 11. Mar 2013, at 20:21, Dave wrote:
try
myDict = [super newDict];
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.app
On 11 Mar 2013, at 20:21, Dave wrote:
> Hi,
>
> Take the following example:
>
> @interface BaseClass
>
> +(NSMutableDictionary*) newDict;
>
> @end
>
> @implementation BaseClass
>
> +(NSMutableDictionary*) newDict
> {
>
>
> return [[NSMutableDictionary alloc] init];
> }
>
>
> @class New
On Tue, Feb 10, 2009 at 1:10 PM, Jean-Daniel Dupas
wrote:
> Just for the record, you can also compare class, but not with the
> isKindOfClass: method.
>
> The method below is similar too ([value isKindOfClass:[NSString class]])
>
> [[value class] isSubclassOfClass:[NSString class]]
Yes, to be c
Le 10 févr. 09 à 18:33, I. Savant a écrit :
On Tue, Feb 10, 2009 at 12:26 PM, Mike Abdullah
wrote:
Read the documentation on -isKindOfClass: again. It does exactly
what you
want. -isMemberOfClass: performs the more specific test of excluding
subclasses.
In addition, a common gotcha (for
On Tue, Feb 10, 2009 at 12:26 PM, Mike Abdullah
wrote:
> Read the documentation on -isKindOfClass: again. It does exactly what you
> want. -isMemberOfClass: performs the more specific test of excluding
> subclasses.
In addition, a common gotcha (for me, anyway - it still gets me now
and again)
On Feb 10, 2009, at 10:16 AM, Andy Bettis wrote:
I have an id object that I'd like to test to see if it's a certain
class or a subclass of that class. isKindOfClass gives a very
specific test, is there an easy way to test for an object being a
subclass of a class?
That's exactly what -isK
On Feb 10, 2009, at 12:16 PM, Andy Bettis wrote:
I have an id object that I'd like to test to see if it's a certain
class or a subclass of that class. isKindOfClass gives a very
specific test, is there an easy way to test for an object being a
subclass of a class?
See isMemberOfClass:, w
Read the documentation on -isKindOfClass: again. It does exactly what
you want. -isMemberOfClass: performs the more specific test of
excluding subclasses.
On 10 Feb 2009, at 17:16, Andy Bettis wrote:
I have an id object that I'd like to test to see if it's a certain
class or a subclass of
53 matches
Mail list logo
