Re: assign property behaves differently from simple instance variable???
On Mon, 13 Dec 2010 11:31:38 -0800, Wim Lewis w...@omnigroup.com said: On 13 Dec 2010, at 11:01 AM, Matt Neuburg wrote: How can this seemingly minor change make such a big difference? I'm not even *using* the synthesized accessor! Yet its mere presence breaks the project. How can this be? m. PS A new discovery: changing the name of the ivar / property to fr solves the problem. So it appears that the problem is that I'm synthesizing accessors for the *name* firstResponder. It is as if this name was being used under the hood in some way I'm unaware of, and synthesizing an accessor breaks its use. But how can *that* be? Perhaps it stomps on the -isFirstResponder method? KVC access for 'foo' checks (among other things) '-isFoo', presumably so that boolean properties feel natural; perhaps synthesizing a 'foo' property likewise causes the object to respond to 'isFoo'. Hmm, also, it appears that UIResponder has some undocumented methods -firstResponder and -_firstResponder, which your synthesized property would also interfere with. Doubtless. But how would I have discovered this? Doesn't anyone besides me want to evince any outrage that this can happen? I mean, sheesh, if I wanted to live in a world where the namespace was polluted with secret undocumented terminology I could collide with accidentally, I could use AppleScript. m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ A fool + a tool + an autorelease pool = cool! AppleScript: the Definitive Guide - Second Edition! http://www.apeth.net/matt/default.html#applescriptthings___ 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.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: assign property behaves differently from simple instance variable???
On Dec 13, 2010, at 12:01 PM, Matt Neuburg wrote: self-firstResponder = tf; Well, the proper syntax is self.firstResponder . Using the deference is probably a back-door way to access the class struct. Unless I misunderstand something Keary Suska Esoteritech, Inc. Demystifying technology for your home or business ___ 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.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: assign property behaves differently from simple instance variable???
On Dec 14, 2010, at 10:01 AM, Keary Suska wrote: On Dec 13, 2010, at 12:01 PM, Matt Neuburg wrote: self-firstResponder = tf; Well, the proper syntax is self.firstResponder . Using the deference is probably a back-door way to access the class struct. Unless I misunderstand something 'self-foo' is equivalent to 'foo' (both are transformed into an appropriate offset into instance storage). self.foo is equivalent to [self foo] or [self setFoo:] depending on context. -- David Duncan ___ 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.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: assign property behaves differently from simple instance variable???
On Dec 14, 2010, at 10:01 AM, Keary Suska wrote: On Dec 13, 2010, at 12:01 PM, Matt Neuburg wrote: self-firstResponder = tf; Well, the proper syntax is self.firstResponder . Using the deference is probably a back-door way to access the class struct. Unless I misunderstand something You do; that's irrelevant to the example. Indeed, I deliberately left the code looking this way in order to emphasize the fact that synthesizing the accessors for firstResponder breaks the app even if I never use them. m. -- matt neuburg, phd = m...@tidbits.com, http://www.tidbits.com/matt/ pantes anthropoi tou eidenai oregontai phusei Among the 2007 MacTech Top 25, http://tinyurl.com/2rh4pf AppleScript: the Definitive Guide, 2nd edition http://www.tidbits.com/matt/default.html#applescriptthings Take Control of Exploring Customizing Snow Leopard http://tinyurl.com/kufyy8 RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com ___ 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.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: assign property behaves differently from simple instance variable???
Hmm, also, it appears that UIResponder has some undocumented methods -firstResponder and -_firstResponder, which your synthesized property would also interfere with. Doubtless. But how would I have discovered this? I would have implemented -firstResponder and set a breakpoint to see who was calling it. You could also use otool or class-dump to get a listing of methods that UIResponder implements. Doesn't anyone besides me want to evince any outrage that this can happen? I mean, sheesh, if I wanted to live in a world where the namespace was polluted with secret undocumented terminology I could collide with accidentally, I could use AppleScript. m. Hah – Cocoa/Obj-C certainly has its shortcomings, but comparing it to AppleScript? Ouch. There was an interesting discussion about bringing namespaces to Obj-C on cfe-dev last month: http://comments.gmane.org/gmane.comp.compilers.clang.devel/11746 Needless to say it's no small task, and the method-overriding problem raised in this thread might not even be solved by Obj-C namespaces, as it would depend entirely on how comprehensive the implementation was. ___ 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.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: assign property behaves differently from simple instance variable???
On Dec 14, 2010, at 9:01 AM, Matt Neuburg m...@tidbits.com wrote: Doesn't anyone besides me want to evince any outrage that this can happen? I mean, sheesh, if I wanted to live in a world where the namespace was polluted with secret undocumented terminology I could collide with accidentally, I could use AppleScript. m. The only thing that infuriates me more than the time spent hunting down name collisions with private APIs is the insistence from some parties that ObjC namespaces are a solution in search of a problem. In a world with KVC/KVO where prefixing method names to ensure uniqueness is no longer feasible, Apple needs to deliver namespaces for ObjC. Hacks like private API begins with underscore aren't enough to deal with public/private namespace collisions or multiple similarly-named classes being loaded dynamically into the same process. The only real way to get that point across is to keep filing Radars when situations like this arise. --Kyle Sluder___ 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.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
assign property behaves differently from simple instance variable???
I have reduced this problem (after losing an entire day of work, of course) to
a very few lines of code. They won't make much sense but just bear with me.
Here we go...
I have this code (iOS), and it works fine:
@interface TextFieldFunViewController : UIViewController {
UIView* firstResponder;
}
//@property (nonatomic, assign) UIView* firstResponder;
@end
@implementation TextFieldFunViewController
//@synthesize firstResponder;
- (void)textFieldDidBeginEditing:(UITextField *)tf {
self-firstResponder = tf;
}
- (BOOL)textFieldShouldReturn: (UITextField*) tf {
[tf resignFirstResponder];
return NO;
}
@end
Notice that I'm not *doing* anything with my ivar firstResponder. The code
works: I tap in my text field, and the keyboard appears; then I tap Return and
the keyboard vanishes. I can do this repeatedly until the cows come home.
Now I'll change the code so that firstResponder is backed by a property with a
synthesized accessor - just uncomment the two commented lines in the above.
This change breaks the project! I tap in my text field, the keyboard appears; I
tap Return and the keyboard vanishes; and the text field becomes completely
unresponsive forever after that.
How can this seemingly minor change make such a big difference? I'm not even
*using* the synthesized accessor! Yet its mere presence breaks the project. How
can this be? m.
PS A new discovery: changing the name of the ivar / property to fr solves the
problem. So it appears that the problem is that I'm synthesizing accessors for
the *name* firstResponder. It is as if this name was being used under the
hood in some way I'm unaware of, and synthesizing an accessor breaks its use.
But how can *that* be?
--
matt neuburg, phd = m...@tidbits.com, http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
Among the 2007 MacTech Top 25, http://tinyurl.com/2rh4pf
AppleScript: the Definitive Guide, 2nd edition
http://www.tidbits.com/matt/default.html#applescriptthings
Take Control of Exploring Customizing Snow Leopard
http://tinyurl.com/kufyy8
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
___
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.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: assign property behaves differently from simple instance variable???
On 13 Dec 2010, at 11:01 AM, Matt Neuburg wrote: How can this seemingly minor change make such a big difference? I'm not even *using* the synthesized accessor! Yet its mere presence breaks the project. How can this be? m. PS A new discovery: changing the name of the ivar / property to fr solves the problem. So it appears that the problem is that I'm synthesizing accessors for the *name* firstResponder. It is as if this name was being used under the hood in some way I'm unaware of, and synthesizing an accessor breaks its use. But how can *that* be? Perhaps it stomps on the -isFirstResponder method? KVC access for 'foo' checks (among other things) '-isFoo', presumably so that boolean properties feel natural; perhaps synthesizing a 'foo' property likewise causes the object to respond to 'isFoo'. Hmm, also, it appears that UIResponder has some undocumented methods -firstResponder and -_firstResponder, which your synthesized property would also interfere with. ___ 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.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: assign property behaves differently from simple instance variable???
On Dec 13, 2010, at 1:31 PM, Wim Lewis wrote: On 13 Dec 2010, at 11:01 AM, Matt Neuburg wrote: How can this seemingly minor change make such a big difference? I'm not even *using* the synthesized accessor! Yet its mere presence breaks the project. How can this be? m. PS A new discovery: changing the name of the ivar / property to fr solves the problem. So it appears that the problem is that I'm synthesizing accessors for the *name* firstResponder. It is as if this name was being used under the hood in some way I'm unaware of, and synthesizing an accessor breaks its use. But how can *that* be? Perhaps it stomps on the -isFirstResponder method? KVC access for 'foo' checks (among other things) '-isFoo', presumably so that boolean properties feel natural; perhaps synthesizing a 'foo' property likewise causes the object to respond to 'isFoo'. Hmm, also, it appears that UIResponder has some undocumented methods -firstResponder and -_firstResponder, which your synthesized property would also interfere with. A collision is most likely the case here. That is why several years ago I adopted a coding practice of ensuring all my methods, keys, properties, etc. are completely unique. For the specific case of properties and methods, I do this: BOOL firstResponder_II; - (BOOL)firstResponder_II; - (void)someMethod_II:(int)anInt with:(int)foo multiple:(int)bar parameters:(int)baz; ___ Ricky A. Sharp mailto:rsh...@instantinteractive.com Instant Interactive(tm) http://www.instantinteractive.com ___ 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.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
