Re: Stupid objective-c question

On 27 Sep 2016, at 05:31, Britt Durbrow wrote: > > FWIW, it’s currently an implementation detail that SELs do map into the > global address space in a way that doesn’t collide with anything else; but > technically, they are in their own address space and

Re: Stupid objective-c question

On 27 Sep 2016, at 02:17, Slipp Douglas Thompson wrote: > > I'm just going to throw this out there as a solution, not because I recommend > this approach (it's API misuse after all) but because it would work. > > Instead of using an `NSString *` you could use a

Re: Stupid objective-c question

FWIW, it’s currently an implementation detail that SELs do map into the global address space in a way that doesn’t collide with anything else; but technically, they are in their own address space and the system could map them otherwise in a manner that does have collisions with other stuff. In

Re: Stupid objective-c question

I'm just going to throw this out there as a solution, not because I recommend this approach (it's API misuse after all) but because it would work. Instead of using an `NSString *` you could use a `SEL` (AKA `struct objc_selector *`) since SELs are guaranteed to be unique for each given string

Re: Stupid objective-c question

> On Sep 26, 2016, at 3:31 AM, Slipp Douglas Thompson > wrote: > > I'm sorry if I'm not up to snuff on compiler architecture, but how would a > pointer to the memory address of that same pointer ever collide with any > other pointer? When ***Somebody*** is Doing

Re: Stupid objective-c question

On 23 Sep 2016, at 9:49 PM, Uli Kusterer wrote: > > Are you sure? I only learned Cocoa when it came to OS X, but my impression > was that, while KVC came from NeXT, KVO arrived with bindings … that would > have been 10.3 or 10.4-ish? As I remember, when KVO was

Re: Stupid objective-c question

On Sep 26, 2016, at 02:45 , Britt Durbrow wrote: > >> void *kMyContext = >> >> is *guaranteed* to give you a unique address that nobody else's object may >> occupy? >> > > Splitting hairs, but that’s not ***guaranteed*** - just super highly

Re: Stupid objective-c question

> > void *kMyContext = > > is *guaranteed* to give you a unique address that nobody else's object may > occupy? > Splitting hairs, but that’s not ***guaranteed*** - just super highly unlikely to have a collision. There’s never any guarantee that somebody else isn’t Doing It Wrong

Re: Stupid objective-c question

> On 24 Sep 2016, at 12:13 PM, Uli Kusterer > wrote: > >> I expect the first thing -isEqualToString: does is a pointer comparison, so >> it’s unlikely to be significantly less performant for the case of when the >> pointers are literally identical. > > No,

Re: Stupid objective-c question

On 23 Sep 2016, at 01:19, Sandor Szatmari wrote: > // my .m file > static NSString * const kMyContext = @"my fantastic context"; This avoids the issue of having a different string in a different module and relying on details of your compiler and its optimizer.

Re: Stupid objective-c question

> On 23 Sep 2016, at 01:07, Quincey Morris > wrote: > > On Sep 22, 2016, at 15:45 , Gabriel Zachmann wrote: >> >> Sure, but an observation method is what would be called a "callback" in >> plain C. >> In C, I can have many different

Re: Stupid objective-c question

On 23 Sep 2016, at 00:45, Gabriel Zachmann wrote: >> Because the observer is an object. Your observation and a superclass >> observation come from the same object. Whether these are to be treated as >> different observations** cannot be determined automatically, hence the

Re: Stupid objective-c question

> On 22 Sep 2016, at 19:53, Quincey Morris > wrote: > > On Sep 22, 2016, at 03:16 , Gabriel Zachmann wrote: >> >> That makes me wonder: why isn't it possible to register several, different >> observers for the same thing? >> That

Re: Stupid objective-c question

On 22 Sep 2016, at 04:00, Doug Hill wrote: > As to the context type, I would be interested to know of cases where the > observer doesn't have control over the context. As your quote says: > "Contexts chosen in a similar manner in the super- or subclass will be > unlikely

Re: Stupid objective-c question

> On 22 Sep 2016, at 03:36, Graham Cox wrote: > > >> On 22 Sep 2016, at 10:40 AM, Quincey Morris >> wrote: >> >> On Sep 21, 2016, at 17:01 , Graham Cox wrote: >>> >>> This should be:

Re: Stupid objective-c question

> On 22 Sep 2016, at 03:21, Slipp Douglas Thompson > wrote: > > >> On Sep 21, 2016, at 8:00 PM, Slipp Douglas Thompson >> wrote: >> >>> On Sep 21, 2016, at 17:01 , Graham Cox wrote: This should

Re: Stupid objective-c question

> On 22 Sep 2016, at 02:05, Gabriel Zachmann wrote: >> >>> how can the compiler know that '==' in this case is a NSString comparison? >> >> It can’t because it isn't. What’s being compared are raw pointers. The >> string value is irrelevant. > > Let me try to

Re: Stupid objective-c question

On 22 Sep 2016, at 02:02, Doug Hill wrote: >>> My question is: how can the compiler know that '==' in this case is a >>> NSString comparison? >>> Or is some other magic going on here? if so, which? >>> Does the compiler know it should perform some kind of dynamic method >>>

Re: Stupid objective-c question

> On 22 Sep 2016, at 02:01, Graham Cox wrote: > > >> On 22 Sep 2016, at 9:44 AM, Gabriel Zachmann wrote: >> >> I have found on the net > > That isn’t always a recommendation ;) > > >> if ( context == (__bridge void *) @"mediaLibraryLoaded" )

Re: Stupid objective-c question

Thanks to both of you for clarifying this and for a nice solution. Basically then, I must not use address pointed to, but instead, the address of the pointer itself. I liked the readability of using a string, but I think there is too much room for misinterpretation, conflating the contents of

Re: Stupid objective-c question

On 23 Sep 2016, at 10:04, Quincey Morris wrote: > >> static void* kMyContext = > > That makes the “&” optional (at comparison time), and it should even avoid > the coalescing problem if it’s declared const. Yes, that’s a good way to do it. It might be a

Re: Stupid objective-c question

> On 23 Sep 2016, at 10:04, Quincey Morris > wrote. > > As previously mentioned, the safest way to do this is: > >> static void* kMyContext = > Thats a neat trick. It’s not an initialisation that I have seen before and on first glance I thought it was a

Re: Stupid objective-c question

On Sep 23, 2016, at 01:36 , Alastair Houghton wrote: > > Note that you can use *any* type for your variable; in some ways, it might > make sense to use a non-pointer type, just to make clear that it’s the > address that matters, e.g. > > static const int

Re: Stupid objective-c question

On 23 Sep 2016, at 09:36, Alastair Houghton wrote: > > Note that you can use *any* type for your variable; in some ways, it might > make sense to use a non-pointer type, just to make clear that it’s the > address that matters, e.g. > > static const int

Re: Stupid objective-c question

On 23 Sep 2016, at 00:07, Quincey Morris wrote: > > On Sep 22, 2016, at 15:45 , Gabriel Zachmann wrote: >> >> Sure, but an observation method is what would be called a "callback" in >> plain C. >> In C, I can have many different

Re: Stupid objective-c question

On 23 Sep 2016, at 00:19, Sandor Szatmari wrote: > > I wanted to get some opinions on the following which I have done in the past > and perceive as different because the string constant is introduced and > defined once and only once. > > // my .m file > static

Re: Stupid objective-c question

On Sep 22, 2016, at 16:52 , Charles Srstka wrote: > > Actually nope, it showed up in 10.3, making it younger than the > target/selector approach. In that case, I have no plausible rationale why this was done differently. It’s possible there was a performance-related

Re: Stupid objective-c question

> On Sep 22, 2016, at 4:19 PM, Sandor Szatmari > wrote: > > So there was lots of discussion and plenty of 'don't do anything that equates > to this' --> @"myString" == @"myString", and I agree. > > I wanted to get some opinions on the following which I have

Re: Stupid objective-c question

> On Sep 22, 2016, at 6:07 PM, Quincey Morris > wrote: > > But that’s because the KVO notification mechanism is a more ancient design > concept, where it likely seemed simple, adequate and flexible. I assume it > comes from NeXTStep days (late 80s or early

Re: Stupid objective-c question

So there was lots of discussion and plenty of 'don't do anything that equates to this' --> @"myString" == @"myString", and I agree. I wanted to get some opinions on the following which I have done in the past and perceive as different because the string constant is introduced and defined

Re: Stupid objective-c question

> On Sep 22, 2016, at 3:45 PM, Gabriel Zachmann wrote: > > I don't see why that should not be possible in Obj-C - I just would need a > mechanism to add tell the system the names / function pointers to be > registered as observers. That’s more like the way

Re: Stupid objective-c question

On Sep 22, 2016, at 15:45 , Gabriel Zachmann wrote: > > Sure, but an observation method is what would be called a "callback" in plain > C. > In C, I can have many different callbacks. > I don't see why that should not be possible in Obj-C - I just would need a > mechanism

Re: Stupid objective-c question

> > Because the observer is an object. Your observation and a superclass > observation come from the same object. Whether these are to be treated as > different observations** cannot be determined automatically, hence the need > for a “context”. Sure, but an observation method is what would

Re: Stupid objective-c question

On Sep 22, 2016, at 03:16 , Gabriel Zachmann wrote: > > That makes me wonder: why isn't it possible to register several, different > observers for the same thing? > That way, I wouldn't need to care about observations I didn't create, would I? Because the observer is an

Re: Stupid objective-c question

On Sep 21, 2016, at 21:47 , Jeff Evans wrote: > > Of course, so [[NSArray alloc]init] is actually useless; I hadn't thought of > that. No one would ever declare an array that way. Just continuing my nitpicking tour of this thread: It isn’t useless. Sometimes you really

Re: Stupid objective-c question

> On Sep 21, 2016, at 9:47 PM, Jeff Evans wrote: > > One would have to init it with objects to be useful at all, and then it > presumably would point to different data than another NSArray (even > nonmutable) inited with objects. Yup. Another fun fact is that the

Re: Stupid objective-c question

> On Sep 21, 2016, at 10:07 PM, Quincey Morris > wrote: > > On Sep 21, 2016, at 21:10 , Doug Hill > wrote: >> >> I believe the original question was why you can compare a string literal to >> another

Re: Stupid objective-c question

On Sep 21, 2016, at 21:10 , Doug Hill wrote: > > I believe the original question was why you can compare a string literal to > another object pointer using the == operator and it somehow works. Actually, we’re more or less on the same page here, but for posterity… There’s

Re: Stupid objective-c question

Ah - yes, thank you. Of course, so [[NSArray alloc]init] is actually useless; I hadn't thought of that. No one would ever declare an array that way. One would have to init it with objects to be useful at all, and then it presumably would point to different data than another NSArray (even

Re: Stupid objective-c question

> On Sep 21, 2016, at 9:19 PM, Jeff Evans wrote: > > Is it really true what Jens says, that [[NSArray alloc]init] always > returns the same pointer? > If that is the case, how can one declare two separate arrays? NSArray is immutable, so any two empty

Re: Stupid objective-c question

I think it’s because an NSArray is immutable such that an empty array is guaranteed to never change. This gives the compiler opportunities for optimization based on this knowledge. It starts to get interesting when you do things like: NSArray *emptyArray = [[NSArray alloc] init]; NSArray

Re: Stupid objective-c question

Whoa - maybe I've had too much wine with dinner, but: Is it really true what Jens says, that [[NSArray alloc]init] always returns the same pointer? If that is the case, how can one declare two separate arrays? Jeff On Sep 21, 2016, at 8:50 PM, Jens Alfke wrote: > On Sep 21,

Re: Stupid objective-c question

> On Sep 21, 2016, at 8:33 PM, Quincey Morris > wrote: > > On Sep 21, 2016, at 19:00 , Doug Hill > wrote: >> >> Just to be clear, the original question was specifically about comparing an >> Objective-C

Re: Stupid objective-c question

> On Sep 21, 2016, at 7:00 PM, Doug Hill wrote: > > As to the context type, I would be interested to know of cases where the > observer doesn't have control over the context. My understanding is that the > context is something that the observer sets itself when calling

Re: Stupid objective-c question

> On Sep 21, 2016, at 6:36 PM, Graham Cox wrote: > > Which is yet another reason why void* is such a shitty concept. Apple could > easily have insisted that parameter was id without any real > problems, so void*… sheesh. It’s not an object! It’s just an opaque

Re: Stupid objective-c question

On Sep 21, 2016, at 19:00 , Doug Hill wrote: > > Just to be clear, the original question was specifically about comparing an > Objective-C string literal. For this case, you definitely want to use > -[NSString isEqualToString:] Actually, no. A couple of similar comments

Re: Stupid objective-c question

On Sep 21, 2016, at 7:00 PM, Doug Hill wrote: > As to the context type, I would be interested to know of cases where the > observer doesn't have control over the context. My understanding is that the > context is something that the observer sets itself when calling

Re: Stupid objective-c question

> On Sep 21, 2016, at 6:36 PM, Graham Cox wrote: > > >> On 22 Sep 2016, at 10:40 AM, Quincey Morris >> wrote: >> >> On Sep 21, 2016, at 17:01 , Graham Cox wrote: >>> >>> This should be:

Re: Stupid objective-c question

> On 22 Sep 2016, at 10:40 AM, Quincey Morris > wrote: > > On Sep 21, 2016, at 17:01 , Graham Cox wrote: >> >> This should be: if([(NSString*)context >> isEqualToString:@“mediaLibraryLoaded”])… > > Actually, this is not a good

Re: Stupid objective-c question

On Sep 21, 2016, at 18:00 , Slipp Douglas Thompson wrote: > > isEqualToString: could cause issues here so isEqual: is the most sure-fire > solution Er, no. If the context is not an object, [context isEqual: … anything …] is going to crash in objc_msgSend before

Re: Stupid objective-c question

> On Sep 21, 2016, at 8:00 PM, Slipp Douglas Thompson > wrote: > >> On Sep 21, 2016, at 17:01 , Graham Cox wrote: >>> >>> This should be: if([(NSString*)context >>> isEqualToString:@“mediaLibraryLoaded”])… >> >> Actually, this is not a

Re: Stupid objective-c question

> On Sep 21, 2016, at 17:01 , Graham Cox wrote: >> >> This should be: if([(NSString*)context >> isEqualToString:@“mediaLibraryLoaded”])… > > Actually, this is not a good idea either, because *other* observations — ones > you don’t control — might use a value that’s not

Re: Stupid objective-c question

On Sep 21, 2016, at 17:01 , Graham Cox wrote: > > This should be: if([(NSString*)context > isEqualToString:@“mediaLibraryLoaded”])… Actually, this is not a good idea either, because *other* observations — ones you don’t control — might use a value that’s not an object,

Re: Stupid objective-c question

> Whenever I have two string literals @"XYZ" at different places in the same > compilation unit, > and the XYZ are identical, then the compiler (or the Objective-C standard) > make sure that > the pointers to those literals are identical? > > In other words, the compiler unifies the two

Re: Stupid objective-c question

On Sep 21, 2016, at 17:05 , Gabriel Zachmann wrote: > > In other words, the compiler unifies the two occurrences of the two literals, > thus effectively storing only one literal? Correct. > So what would be the proper way to do it? A global variable has a fixed, unique

Re: Stupid objective-c question

> On Sep 21, 2016, at 4:44 PM, Gabriel Zachmann wrote: > > My question is: how can the compiler know that '==' in this case is a > NSString comparison? It doesn’t. In Obj-C, “==“ is always a pointer comparison even if it’s applied to objects. It is NOT the same as

Re: Stupid objective-c question

>> >> how can the compiler know that '==' in this case is a NSString comparison? > > It can’t because it isn't. What’s being compared are raw pointers. The string > value is irrelevant. Let me try to paraphrase, in order to check whether I am understanding correctly. Whenever I have two

Re: Stupid objective-c question

> On Sep 21, 2016, at 4:52 PM, Steve Mills wrote: > >> On Sep 21, 2016, at 18:44, Gabriel Zachmann wrote: >> >> I've got a stupid, curious question regarding a code snippet that I have >> found on the net (I tried it, it works). >> >> Here is the code

Re: Stupid objective-c question

> On 22 Sep 2016, at 9:44 AM, Gabriel Zachmann wrote: > > I have found on the net That isn’t always a recommendation ;) > if ( context == (__bridge void *) @"mediaLibraryLoaded" ) Don’t do this, even if it appears to work. You got lucky, or are taking advantage of

Re: Stupid objective-c question

It’s doing a pointer comparison while making poor assumptions about how the compiler will optimize the storage of string constants. This is bad; DO NOT DO THIS. Dan > On Sep 21, 2016, at 4:44 PM, Gabriel Zachmann wrote: > > I've got a stupid, curious question regarding

Re: Stupid objective-c question

> On Sep 21, 2016, at 18:44, Gabriel Zachmann wrote: > > I've got a stupid, curious question regarding a code snippet that I have > found on the net (I tried it, it works). > > Here is the code snippet: > > - (void) observeValueForKeyPath: (NSString *) keyPath

Re: Stupid objective-c question

On Sep 21, 2016, at 16:44 , Gabriel Zachmann wrote: > > how can the compiler know that '==' in this case is a NSString comparison? It can’t because it isn't. What’s being compared are raw pointers. The string value is irrelevant. > Or is some other magic going on here?

Stupid objective-c question

I've got a stupid, curious question regarding a code snippet that I have found on the net (I tried it, it works). Here is the code snippet: - (void) observeValueForKeyPath: (NSString *) keyPath ofObject: (id) object change: (NSDictionary *) change context: (void *)

Re: Objective-C Question about Categories and Subclasses

> 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

Re: Objective-C Question about Categories and Subclasses

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

Objective-C Question about Categories and Subclasses

Hi, If I have a category on a class (call it LTWClassX) with a method called -(void) foo; If I then subclass from LTWClassX - call it LTWClassY. What happens if I now define foo in the Subclass? I’m guessing it overrides it? Right? Thanks a lot Dave

Re: Objective-C Question

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 d...@looktowindward.com wrote: If that is the case, then how do you signal to the compiler/ analyzer that you are returning a

Re: Another Gnarly Objective-C Question!

On 13 Mar 2013, at 09:13, Jean-Daniel Dupas wrote: Le 13 mars 2013 à 01:55, Wim Lewis w...@omnigroup.com a écrit : On 12 Mar 2013, at 2:08 AM, Graham Cox wrote: in a + method, [self class] === self. Once you've got that, you've got it. You're overthinking this. A class method is

Re: Objective-C Question

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]

Re: Objective-C Question

Le 14 mars 2013 à 11:12, Richard Heard heard...@gmail.com 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.

Re: Objective-C Question

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 devli...@shadowlab.org wrote: Le 14 mars 2013 à 11:12, Richard Heard heard...@gmail.com a écrit : Your logic is

Re: Objective-C Question

On 12 Mar 2013, at 21:34, Graham Cox wrote: On 13/03/2013, at 6:53 AM, Dave d...@looktowindward.com 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

Re: Another Gnarly Objective-C Question!

Le 13 mars 2013 à 01:55, Wim Lewis w...@omnigroup.com a écrit : On 12 Mar 2013, at 2:08 AM, Graham Cox wrote: in a + method, [self class] === self. Once you've got that, you've got it. You're overthinking this. A class method is just an instance method of the class object. No magic

Re: Objective-C Question

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 d...@looktowindward.com 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

Re: Objective-C Question

On 12 Mar 2013, at 21:25, Graham Cox wrote: On 13/03/2013, at 2:41 AM, Dave d...@looktowindward.com 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

Moderator - Re: Objective-C Question

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

Re: Objective-C Question

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 d...@looktowindward.com wrote: If that is the case, then how do you signal to the compiler/ analyzer that you are returning a

Re: Another Gnarly Objective-C Question!

On Mar 13, 2013, at 2:13 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 13 mars 2013 à 01:55, Wim Lewis w...@omnigroup.com a écrit : On 12 Mar 2013, at 2:08 AM, Graham Cox wrote: in a + method, [self class] === self. Once you've got that, you've got it. You're overthinking this.

Re: Another Gnarly Objective-C Question!

Le 13 mars 2013 à 18:13, John McCall rjmcc...@apple.com a écrit : On Mar 13, 2013, at 2:13 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 13 mars 2013 à 01:55, Wim Lewis w...@omnigroup.com a écrit : On 12 Mar 2013, at 2:08 AM, Graham Cox wrote: in a + method, [self class] === self.

Re: Objective-C Question

On 11 Mar 2013, at 21:45, John McCall wrote: On Mar 11, 2013, at 2:02 PM, Dave d...@looktowindward.com wrote: On 11 Mar 2013, at 20:53, John McCall wrote: On Mar 11, 2013, at 1:33 PM, Dave d...@looktowindward.com wrote: On 11 Mar 2013, at 20:26, Mike Abdullah wrote: I had assumed (and

Re: Objective-C Question

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

Another Gnarly Objective-C Question!

Hi All, Thanks for all help on the last question, here is one on a similar vein: This is all Class methods, no instances are allocated or intended to be allocated at this stage. in + Method in a subclass: [[self class] someMethod]; This calls +someMethod in the current class, if it

Re: Objective-C Question

On 12/03/2013, at 6:31 PM, Dave d...@looktowindward.com 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

Re: Another Gnarly Objective-C Question!

On 12/03/2013, at 7:39 PM, Dave d...@looktowindward.com wrote: Hi All, Thanks for all help on the last question, here is one on a similar vein: This is all Class methods, no instances are allocated or intended to be allocated at this stage. in + Method in a subclass: [[self class]

Re: Objective-C Question

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

Re: Objective-C Question

On 12/03/2013, at 11:45 PM, Dave d...@looktowindward.com 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

Re: Objective-C Question

On 12 Mar 2013, at 13:37, Graham Cox wrote: On 12/03/2013, at 11:45 PM, Dave d...@looktowindward.com wrote: Except it doesn't do what the above does! Yes it does. Oh No it doesn't! crowd echo's Oh Yes it does! It creates a copy of read only dictionary and then modifies that. If

Re: Objective-C Question

On Mar 12, 2013, at 12:31 AM, Dave d...@looktowindward.com wrote: On 11 Mar 2013, at 21:45, John McCall wrote: On Mar 11, 2013, at 2:02 PM, Dave d...@looktowindward.com wrote: On 11 Mar 2013, at 20:53, John McCall wrote: On Mar 11, 2013, at 1:33 PM, Dave d...@looktowindward.com wrote: On 11

Re: Objective-C Question

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

Re: Another Gnarly Objective-C Question!

On Mar 12, 2013, at 2:08 AM, Graham Cox graham@bigpond.com wrote: A class method is just an instance method of the class object. No magic at all. So all this confusion you've caused yourself about [super class] and so on is wholly unnecessary to correctly use class methods. Agreed.

Re: Objective-C Question

On Mar 12, 2013, at 9:44 AM, John McCall rjmcc...@apple.com 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

Re: Objective-C Question

On 12 Mar 2013, at 18:50, Jens Alfke wrote: On Mar 12, 2013, at 9:44 AM, John McCall rjmcc...@apple.com 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

Re: Objective-C Question

Le 12 mars 2013 à 20:15, Dave d...@looktowindward.com a écrit : On 12 Mar 2013, at 18:50, Jens Alfke wrote: On Mar 12, 2013, at 9:44 AM, John McCall rjmcc...@apple.com wrote: However, that wouldn't be an idiomatic implementation. The usual expectation is that allocating methods,

Re: Objective-C Question

On 12 Mar 2013, at 19:38, Jean-Daniel Dupas wrote: Le 12 mars 2013 à 20:15, Dave d...@looktowindward.com a écrit : On 12 Mar 2013, at 18:50, Jens Alfke wrote: On Mar 12, 2013, at 9:44 AM, John McCall rjmcc...@apple.com wrote: However, that wouldn't be an idiomatic implementation. The

Re: Objective-C Question

On 13/03/2013, at 2:41 AM, Dave d...@looktowindward.com 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

Re: Objective-C Question

On 13/03/2013, at 6:53 AM, Dave d...@looktowindward.com 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

Re: Another Gnarly Objective-C Question!

On 12 Mar 2013, at 2:08 AM, Graham Cox wrote: in a + method, [self class] === self. Once you've got that, you've got it. You're overthinking this. A class method is just an instance method of the class object. No magic at all. So all this confusion you've caused yourself about [super

Objective-C Question

Hi, Take the following example: @interface BaseClass +(NSMutableDictionary*) newDict; @end @implementation BaseClass +(NSMutableDictionary*) newDict { return [[NSMutableDictionary alloc] init]; } @class NewClass; @interface NewClass : BaseClass +(NSMutableDictionary*) newDict; @end

Re: Objective-C Question

On 11 Mar 2013, at 20:21, Dave d...@looktowindward.com wrote: Hi, Take the following example: @interface BaseClass +(NSMutableDictionary*) newDict; @end @implementation BaseClass +(NSMutableDictionary*) newDict { return [[NSMutableDictionary alloc] init]; } @class

Objective-C Question

Typeo: return [[NSMutableDictionary alloc] init]; should be: return myDict; --- Hi, Take the following example: @interface BaseClass +(NSMutableDictionary*) newDict; @end @implementation BaseClass +(NSMutableDictionary*)

  1   2   >