Re: What's the point of @properties?
On 21 Sep, 2010, at 18:48, Matt Neuburg wrote: On Mon, 20 Sep 2010 03:56:20 -0700, Chris Hanson c...@me.com said: Don't think of dot syntax as syntactic sugar for sending messages. Think of dot syntax as the way to access the state exposed by an object, and bracket syntax as the way to have an object do something. No, I think that's bollocks. Dot syntax is *exactly* syntactic sugar for calling the accessor, and using it correctly depends upon keeping that fact firmly in mind. m. I believe what Chris is saying is that you want to /think of/ properties as being state exposition. He isn't saying they're not technically sugar. If you think of them purely as sugar, you're missing the semantic value of using them in the first place. -- michael ___ 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: What's the point of @properties?
On 23.09.2010, at 03:25, Matt Neuburg wrote: In the current version of IB, you can go to Library Classes Outlets and define an outlet name. If you do this and, say, add an outlet name called howdy on some nib object, and draw the outlet with that name, then when the nib loads, setHowdy: will be called on the corresponding instance if it exists - even though there is no ivar with that name. If you don't believe me I'll send you a project that demonstrates. Indeed, I remember when this was the *only* way to define an outlet name; there was no such thing as the IBOutlet hint in Xcode. m. Yeah, and everyone using the class has to re-add the outlet manually to every NIB that instantiates the class. That's just not a good workflow when working in teams unless you like asserting left and right due to unconnected outlets. You want outlets to show up automatically. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ 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: What's the point of @properties?
On Sep 19, 2010, at 9:52 PM, Jim Thomason wrote: So basically, I get a language built-in version of a macro, and an option to use a new syntax that I'm not interested in anyway. Is there something else I'm not seeing or some other utility to them that I don't yet understand? One point nobody mentioned so far: You can use different names for your public property (e.g. an IBOutlet) and your internal storage (i.e. the instance variable). I like to avoid name collisions between local variables and instance variables by using an m prefix on instance variables. Using @synthesize cancelButton = mCancelButton;, I can do that. Instead of declaring the instance variable as an IBOutlet, I can now declare @property (retain) IBOutlet NSButton*cancelButton; and IB will call setCancelButton:, not setMCancelButton:, which wasn't possible without properties. Also, if you are implementing a framework class that is subclassed by the apps linking to your framework, you can keep it binary-stable and avoid fragile base class-problems by only having one real ivar that points to a struct containing the actual ivars. Again, you wouldn't be able to do IBOutlets in that case if you didn't have property declarations, even though you'll end up writing the getter and setter manually. Apart from that, let me emphasize what others have said: It writes getters/setters for you. Every line of code you don't have to write is a line of code you don't have to debug And finally: properties contain additional mark-up on a method. A future version of the Clang Static Analyzer could detect violations of thread-safety in your code and similar issues with help from property declarations. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... ___ 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: What's the point of @properties?
On Wed, 22 Sep 2010 15:16:19 +0200, Uli Kusterer witness.of.teacht...@gmx.net said: One point nobody mentioned so far: You can use different names for your public property (e.g. an IBOutlet) and your internal storage (i.e. the instance variable). I like to avoid name collisions between local variables and instance variables by using an m prefix on instance variables. Using @synthesize cancelButton = mCancelButton;, I can do that. Instead of declaring the instance variable as an IBOutlet, I can now declare @property (retain) IBOutlet NSButton*cancelButton; and IB will call setCancelButton:, not setMCancelButton:, which wasn't possible without properties. Not so. If an outlet in IB is called cancelButton, nib-loading will call setCancelButton: if it exists, and of course setCancelButton: can be a front for anything at all; no instance variable need exist, in fact, let alone one having the same name. m. -- matt neuburg, phd = m...@tidbits.com, http://www.tidbits.com/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: What's the point of @properties?
On or about 9/22/10 5:06 PM, thus spake Ken Ferry kenfe...@gmail.com: but previously you could only make an IBOutlet called cancelButton by having an ivar called cancelButton. That's just not so. Let's not mix apples and oranges. * An outlet is a thing in the nib. * IBOutlet is not an outlet; it's just a phrase in Xcode, acting as a hint to Interface Builder from Xcode; it saves you time, if you wish, by telling Interface Builder that an outlet by this name might be a possibility. But Interface Builder does not, and never did, *require* that hint in order to define an outlet name. In the current version of IB, you can go to Library Classes Outlets and define an outlet name. If you do this and, say, add an outlet name called howdy on some nib object, and draw the outlet with that name, then when the nib loads, setHowdy: will be called on the corresponding instance if it exists - even though there is no ivar with that name. If you don't believe me I'll send you a project that demonstrates. Indeed, I remember when this was the *only* way to define an outlet name; there was no such thing as the IBOutlet hint in Xcode. 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: What's the point of @properties?
On Sun, 19 Sep 2010 13:29:20 -0700, Bill Bumgarner b...@mac.com said: - synthesis just works (pretty much every attempt at hand-rolled atomicity I've seen has been wrong or bog slow) And even if properties did nothing for me beyond writing my accessors for me, it would still be worth it. They don't actually save me from much work; okay, I don't have to write the accessors, but I still have to say @synthesize; and they know nothing about releasing in dealloc. But before properties I used to jump through hoops just so as not to have to declare an ivar, because it was so much work to support it; with properties, that pain in my hands is gone. On Mon, 20 Sep 2010 03:56:20 -0700, Chris Hanson c...@me.com said: Don't think of dot syntax as syntactic sugar for sending messages. Think of dot syntax as the way to access the state exposed by an object, and bracket syntax as the way to have an object do something. No, I think that's bollocks. Dot syntax is *exactly* syntactic sugar for calling the accessor, and using it correctly depends upon keeping that fact firmly in mind. m. -- matt neuburg, phd = m...@tidbits.com, http://www.tidbits.com/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: What's the point of @properties?
Bill Bumgarner b...@mac.com writes: Thus, with the latest bleeding edge compiler, all you need is the @property() (and cleanup in -dealloc) to declare a fully KVO compliant attribute of your class. Is this also supported by the debugger? In XCode 3.x I once tried to omit the iVars but that's not very funny to debug (as it's hard to inspect the property values without manually declared iVars). -- Until the next mail..., Stefan. pgphvyyOqvWWh.pgp Description: PGP signature ___ 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: What's the point of @properties?
On Sep 20, 2010, at 3:30 AM, Stefan Nobis wrote: Bill Bumgarner b...@mac.com writes: Thus, with the latest bleeding edge compiler, all you need is the @property() (and cleanup in -dealloc) to declare a fully KVO compliant attribute of your class. Is this also supported by the debugger? In XCode 3.x I once tried to omit the iVars but that's not very funny to debug (as it's hard to inspect the property values without manually declared iVars). Instance variables are just one way of providing backing storage for a property. Core Data, for example, provides its own mechanisms. You could also do something similar for your own classes. Or you can have properties that expose state which is entirely dynamic, and not backed by any storage of its own (such as the count of a collection). Thus to inspect the property, you need to actually run the getter to access the property. (With, alas, all the caveats that implies.) GDB doesn’t support dot syntax for invoking property getters, so you just need to use bracket syntax when doing it: // Code: @interface Account : NSObject @property (readwrite, copy) NSString *name; @property (readwrite, getter=isEnabled) BOOL enabled; @end // While debugging: (gdb) po [someAccount name] (gdb) print (BOOL)[someAccount isEnabled] If you’re using automatic or manual ivar synthesis, the default name is the same as the ivar, so with a little bit of work you can get the ivar values in gdb: (gdb) po object_getIvar(someAccount, class_getInstanceVariable([someAccount class], name) (gdb) print *((BOOL *)((void *)someAccount + ivar_getOffset(class_getInstanceVariable([someAccount class], enabled))) (Note: Written in Mail, so there may be casting etc. that the above needs to actually work.) Something like that should work well enough to encapsulate in a debugger macro, if someone so desires. -- Chris ___ 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: What's the point of @properties?
On Sep 19, 2010, at 12:52 PM, Jim Thomason wrote: I'm refactoring and updating a lot of my older code, and one of the things I'm finally looking into is declaring things as properties. But...what's the point? I've been trying to read up on the subject and have found a lot of posts and discussion about the subject, but very little of it seems to get down to the meat of what these things are and why I should care about them. At the simplest level, I just look at them as some syntactic sugar. Don't think of @property as syntactic sugar for declaring getter and setter methods. Think of @property as the way to declare the state exposed by an instance of a class, and methods as the way to declare the behavior exposed by an instance of a class. (Or the class itself.) I know I'd get use of the dot syntax (I do need to use @properties to do that, right?), but I'm eschewing it anyway. The same argument applies: Don't think of dot syntax as syntactic sugar for sending messages. Think of dot syntax as the way to access the state exposed by an object, and bracket syntax as the way to have an object do something. Yes, getting or setting state might “do something” behind the scenes, but conceptually you’re more getting or modifying some information “about” the object than treating it like an actor. This is part of why Xcode only offers dot syntax completions for properties declared via @property; it helps maintain the state versus behavior distinction. (Otherwise, it would offer completions like “.retain” and “.copy”.) -- Chris ___ 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: What's the point of @properties?
On 20 Sep 2010, at 11:47, Chris Hanson wrote: GDB doesn’t support dot syntax for invoking property getters, so you just need to use bracket syntax when doing it: Maybe Stefan meant rather that the ivars do not show up in the debugger window. It's a real pain to have to go to the console every time you want to know the value of an ivar, when stepping through your code. I was highly surprised by this behaviour when I first ran into it, and it is the single most important reason why I continue to declare ivars in the @interface block in projects where I otherwise would not have to. António --- Don't believe everything you think --- ___ 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: What's the point of @properties?
Antonio Nunes devli...@sintraworks.com writes: Maybe Stefan meant rather that the ivars do not show up in the debugger window. Yes, that was the point of the question. -- Until the next mail..., Stefan. pgpasS7cYk4A8.pgp Description: PGP signature ___ 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: What's the point of @properties?
On Sep 20, 2010, at 9:23 AM, Stefan Nobis wrote: Antonio Nunes devli...@sintraworks.com writes: Maybe Stefan meant rather that the ivars do not show up in the debugger window. Yes, that was the point of the question. And Chris explained that properties don't necessarily *have* ivars for you to look at anyway. If you want to see its value, then you need to run the print/po command on the gdb command line. -- Seth Willits ___ 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: What's the point of @properties?
On 20 Sep 2010, at 19:27, Seth Willits wrote: And Chris explained that properties don't necessarily *have* ivars for you to look at anyway. If you want to see its value, then you need to run the print/po command on the gdb command line. Fair enough. And what I would like to see, is the debugger window in code being smart enough to show the synthesised properties. Any chance of that ever happening? Cheers, António --- Some things have to be believed to be seen. --Ralph Hodgson --- ___ 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: What's the point of @properties?
On Mon, Sep 20, 2010 at 11:39 AM, Antonio Nunes devli...@sintraworks.com wrote: On 20 Sep 2010, at 19:27, Seth Willits wrote: And Chris explained that properties don't necessarily *have* ivars for you to look at anyway. If you want to see its value, then you need to run the print/po command on the gdb command line. Fair enough. And what I would like to see, is the debugger window in code being smart enough to show the synthesised properties. Any chance of that ever happening? Did you mean synthesized ivars? It is important you be precise. Automatically showing synthesized properties—or any properties at all—would be a bad idea, because methods have side effects, and even calling simple accessors at the wrong time can be detrimental to your program (remember, the debugger can be stopped anywhere; what if it's in the middle of updating the method cache in objc_msgSend, and then you go up a few frames into your own code?). Automatically showing synthesized ivars is a much safer operation, and one I too would like to see in the debugger. --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
Re: What's the point of @properties?
On 20 Sep 2010, at 20:00, Kyle Sluder wrote: Did you mean synthesized ivars? It is important you be precise. Yes that is what I meant. Automatically showing synthesized properties—or any properties at all—would be a bad idea, because methods have side effects, and even calling simple accessors at the wrong time can be detrimental to your program (remember, the debugger can be stopped anywhere; what if it's in the middle of updating the method cache in objc_msgSend, and then you go up a few frames into your own code?). Automatically showing synthesized ivars is a much safer operation, and one I too would like to see in the debugger. Yes, that is what I'd like to see to. Hmmm, I guess this should really move over to xcode-users if we continue the thread. António - Forgiveness is not an occasional act; it is a permanent attitude. --Martin Luther King, Jr - ___ 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
What's the point of @properties?
I'm refactoring and updating a lot of my older code, and one of the things I'm finally looking into is declaring things as properties. But...what's the point? I've been trying to read up on the subject and have found a lot of posts and discussion about the subject, but very little of it seems to get down to the meat of what these things are and why I should care about them. At the simplest level, I just look at them as some syntactic sugar. So I get to write one @property line in my @interface and one @synthesize line in my @implementation (assuming no more complicated behavior, of course). So it's nifty in that I save myself a lot of redundant typing, but realistically? I could accomplish the same thing with a preprocessor macro and have more fine grained control over exactly how my generated methods look. I mean, it's cool and all that it's built in and saves me from writing my own macro, but realistically this isn't terribly interesting. I know I'd get use of the dot syntax (I do need to use @properties to do that, right?), but I'm eschewing it anyway. Again, I've seen all sorts of arguments about people disliking it because it's not objective-Cish or confusion about structs or whatever, but for me, I simply just don't care to use it. I've got lots of existing code that uses methods and I don't see any reason to update. I'm just a stick in the mud sometimes. So basically, I get a language built-in version of a macro, and an option to use a new syntax that I'm not interested in anyway. Is there something else I'm not seeing or some other utility to them that I don't yet understand? -Jim. ___ 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: What's the point of @properties?
On Sep 19, 2010, at 3:52 PM, Jim Thomason wrote: I'm refactoring and updating a lot of my older code, and one of the things I'm finally looking into is declaring things as properties. But...what's the point? [...] Is there something else I'm not seeing or some other utility to them that I don't yet understand? One thing you get is automatic KVO change notifications. When you set a property through its setter, you don't have to use -willChangeValueForKey: and -didChangeValueForKey: in order to trigger -observeValueForKeyPath: messages for those objects observing the property (via -addObserver:). Regards Markus -- __ Markus Spoettl ___ 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: What's the point of @properties?
On Sep 19, 2010, at 1:11 PM, Markus Spoettl wrote: One thing you get is automatic KVO change notifications. When you set a property through its setter, you don't have to use -willChangeValueForKey: and -didChangeValueForKey: in order to trigger -observeValueForKeyPath: messages for those objects observing the property (via -addObserver:). You'd get that anyway. The point of @property was to capture getters and setters into a single syntactic unit such that it is easy to see exactly what should be treated as a property/attribute/data-thingy on any given class. But not just that the set/get methods exist, but: - the memory management policy is now declarative in the interface - atomic vs. nonatomic is declarative - setter/getter can be mapped to other methods (getter=isEnabled, for example) - synthesis just works (pretty much every attempt at hand-rolled atomicity I've seen has been wrong or bog slow) - the IDE can deduce additional details of your code based on declaration (code-sense prefers properties on the RHS of a dot, for example) - minimize lines of code That last point has been achieved in stages. In the move to the modern Objective-C 2.0 ABI (the runtime you get on iPhone and 64 bit Mac OS X), you don't need to declare iVars for @property()s as the compiler will synthesize the storage, too. In llvm 2.0 top-of-tree, @synthesize is on by default for all @properties. Thus, with the latest bleeding edge compiler, all you need is the @property() (and cleanup in -dealloc) to declare a fully KVO compliant attribute of your class. The dot is syntactic convenience and pretty much nothing more. The dot does enforce more compiler checking than regular method invocations, though (can't use dot w/id and the compiler will whine if you use the dot in a non setter/getter role). b.bum (Who is still on the fence as to whether the dot was a good idea; it sure does cause confusion, but damned if it isn't awfully convenient. Sigh.) ___ 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: What's the point of @properties?
On Sep 19, 2010, at 2:52 PM, Jim Thomason wrote: I know I'd get use of the dot syntax (I do need to use @properties to do that, right?) No. Dot syntax is syntactic sugar for invoking accessors. The accessor do not have to be related to a declared property (i.e. @property). Dot syntax works will plain old hand-rolled accessors. Regards, Ken ___ 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
