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 the system could map > them otherwise

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 `SEL` (AKA `struct > objc_selec

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 t

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 It Wrong. Having been bitten

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 introduced, it was framed as a b

Re: Stupid objective-c question

On Sep 26, 2016, at 02:45 , Britt Durbrow wrote: > >> void *kMyContext = &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.

Re: Stupid objective-c question

> > void *kMyContext = &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 I

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, Graham, don't do that! > > There i

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. However, it can still run afoul o

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 callbacks. >> I don't see why that should not be possible i

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 need >> for a “context

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 way, I wouldn't need to care about observations I didn't creat

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 to overlap." It is

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: if([(NSString*)context >>> isEqualToString:@“mediaLibraryLoaded”])… >> >> Actually, this is not a good id

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 be: if([(NSString*)context isEqualToString:@“mediaLibraryLoaded”])… >>> >>> Ac

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 paraphrase, in order to check whe

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 >>> dispatch? >> >> My g

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" ) Gabriel, this is a pointer comparison, not a

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 t

Re: Stupid objective-c question

On 23 Sep 2016, at 10:04, Quincey Morris wrote: > >> static void* kMyContext = &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 good idea for Apple to ha

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 = &kMyContext; > Thats a neat trick. It’s not an initialisation that I have seen before and on first glance I thought it was a typo but it works. I norm

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 kMyContext = 0xabadf00d; > > Otherwi

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 kMyContext = 0xabadf00d; On second tho

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 callbacks. >> I don't see why that should not be possible in Obj

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 NSString * const kMyContext = @"m

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 reason. It’s possible it wa

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 done in the past > and perceive

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 90s), not OS X 10.0 days (early > 20

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 once

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 NSNotificationCenter works — you spe

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 to add tell the system

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 be

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 object. Your observation

Re: Stupid objective-c question

>> 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 addObserver, >> and it is passed back to itself in the above method call.

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 want an empty array. For

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 non-mutable classes all imple

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 object pointer using the == operator and it somehow works. > >

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 no “somehow” with the

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 nonmuta

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 NSArrays are equal/identical.

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

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, 2

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 string literal. For this case, you definitely want to use >>

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 addObserver, > and it i

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 ‘cookie’ that you can use to rec

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 in this thread have sli

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 addObserver, > and it is pass

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: if([(NSString*)context >>> isEqualToString:@“mediaLibraryLoaded”])… >> >> Actually, this is not a good

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 idea either, because *other* observations — ones > you don’t co

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 execution gets to the ‘isEqual’

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 good idea either, because *other* observations — >> on

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, or not even 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 an object, or not even a valid poi

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 occurren

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 memory address, so you

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 -isEqual:. This idiom with

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 stri

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 snippet: >> >> - (void) observeValueFor

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 undocumented implement

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 a code snippet that I

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 ofObject: (id) object >

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? if so, which? No magic,

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

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 moderators

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 (Cocoa-dev@lists.apple.com) Please do

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: Another Gnarly Objective-C Question!

On 13 Mar 2013, at 09:13, Jean-Daniel Dupas wrote: Le 13 mars 2013 à 01:55, Wim Lewis 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 metho

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 wrote: If that is the case, then how do you signal to the compiler/ analyzer that you are returning a retained object? In genera

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 wrote: > Le 14 mars 2013 à 11:12, Richard Heard a écrit : > >> Your logic is clearly flawed. This only seems to r

Re: Objective-C Question

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

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] i

Re: Another Gnarly Objective-C Question!

Le 13 mars 2013 à 18:13, John McCall a écrit : > On Mar 13, 2013, at 2:13 AM, Jean-Daniel Dupas wrote: >> Le 13 mars 2013 à 01:55, Wim Lewis 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. >

Re: Another Gnarly Objective-C Question!

On Mar 13, 2013, at 2:13 AM, Jean-Daniel Dupas wrote: > Le 13 mars 2013 à 01:55, Wim Lewis 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

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 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 - 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 h

Re: Objective-C Question

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

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 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 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 at

Re: Objective-C Question

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

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

Re: Objective-C Question

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

Re: Objective-C Question

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)

Re: Objective-C Question

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

Re: Objective-C Question

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

Re: Objective-C Question

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

Re: Objective-C Question

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

Re: Another Gnarly Objective-C Question!

On Mar 12, 2013, at 2:08 AM, Graham Cox 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. This can be confusing t

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 [Subclass1

Re: Objective-C Question

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: >>> >>

Re: Objective-C Question

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

Re: Objective-C Question

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

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 mi

Re: Another Gnarly Objective-C Question!

On 12/03/2013, at 7:39 PM, Dave 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] someMethod];

Re: Objective-C Question

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

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 exists,

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 think

Re: Objective-C Question

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

Re: Objective-C Question

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: > >>>

Re: Objective-C Question

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?

  1   2   >