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 *)