Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On May 20, 2015, at 7:16 PM, Michael David Crawford wrote: You could comment off their declarations in your header files, then have a look at which uses of them in your sources result in fatal compiler errors. Bingo. That will do it. Thanks much to everyone on this. It's certainly gotten me a little more in touch with the guts of this all. Alex Zavatone ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On May 20, 2015, at 7:17 PM, Jens Alfke wrote: On May 20, 2015, at 4:08 PM, Eric Wing ewmail...@gmail.com wrote: You could use the Objective-C runtime to find out which things are properties. You could, but isn’t it a lot easier to just look at the character before the name and check whether it’s a “.”? —Jens This brings me back to a point of confusion in 2011 where I created properties in a class and accessed them without the self. Or so I thought. Anyway, time for a little research to narrow this down. On another note, I'm with you on disliking autosynthesis. What I like about having to manually create the @synthesis is that this creates a nice little table of contents at the top of my .m file. An easy single place where I can see all the props listed within my class. A point of reference. Putting each property @synthesis on its own line also provides ample room for comments to make everything nice and clear. Also, you can turn it off autosynthesis? How? That would be a big help for me to straighten out this iOS project where the original developers thought everything needed to be a java bean. Thanks much. Alex Zavatone NSBean - it's what happens when you have Java programmers try to create iOS apps. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On 22 May 2015, at 2:28 am, Alex Zavatone z...@mac.com wrote: if you use myThing, it's not visually obvious that you're directly accessing the ivar This is where a consistent and deeply ingrained naming convention is useful. The leading underscore has always been Cocoa’s “way” of doing that, and with auto-synthesis that’s now baked in. But actually because of that, it’s less useful as a naming convention, because it puts you back to square 1 with knowing which is an ivar you added and which is a synthesised property. Because I came to Cocoa from C++, I have long had a habit of prefixing all my ivars with ‘m’ (for ‘member’). Some Cocoa folks don’t like that idiom, but I know that any time I see an access to anything starting with ‘m’ it’s a direct member. Sometimes I do m_ which makes it stand out even more. A lot of sample code seems to encourage the use of ‘my’ for anything that’s not part of the framework, but it quickly becomes overloaded. Whatever you choose, stick to it, that’s the important thing. (Not sure, but it might also be possible to set up syntax colouring so that ivars you declare are highlighted differently). —Graham ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On 22 May 2015, at 3:02 am, Jens Alfke j...@mooseyard.com wrote: Now that I have a path forward and understand why things are what they are, this brings up the wonderful speed issue of how much slower is property access vs ivar access”. Yeah, I think we’ve had some vigorous debates about this topic in the past. Anecdotally, with some coarse measurements to confirm it, I changed a bunch of code in -initWithCoder: to set ivars directly instead of using the property accessors (or -setFoo:). For a very large object graph - I’m talking hundreds of thousands of objects - the speed-up was dramatic. Dearchiving that large file went from 11 MINUTES to about 2 seconds. Because -initWithCoder: is an init method, setting ivars directly is par for the course, and at that time there can’t be any KVO observations depending on the property accessors, so it’s fine. However, if you have autosynthesized all your properties, to be completely safe and future-proof, you probably shouldn’t be doing this, even though right now the ivar names are predictable. That means that performance could be an issue with autosynthesized properties. —Graham ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On May 21, 2015, at 4:44 PM, Graham Cox graham@bigpond.com wrote: On 22 May 2015, at 3:02 am, Jens Alfke j...@mooseyard.com wrote: Now that I have a path forward and understand why things are what they are, this brings up the wonderful speed issue of how much slower is property access vs ivar access”. Yeah, I think we’ve had some vigorous debates about this topic in the past. Anecdotally, with some coarse measurements to confirm it, I changed a bunch of code in -initWithCoder: to set ivars directly instead of using the property accessors (or -setFoo:). For a very large object graph - I’m talking hundreds of thousands of objects - the speed-up was dramatic. Dearchiving that large file went from 11 MINUTES to about 2 seconds. Because -initWithCoder: is an init method, setting ivars directly is par for the course, and at that time there can’t be any KVO observations depending on the property accessors, so it’s fine. However, if you have autosynthesized all your properties, to be completely safe and future-proof, you probably shouldn’t be doing this, even though right now the ivar names are predictable. That means that performance could be an issue with autosynthesized properties. The synthesized ivar name algorithm is not an implementation detail. It is fully specified as follows: the compiler prepends a ‘_’ to the property name. Do not worry about future releases of the language changing the ivar name. John. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On May 21, 2015, at 6:43 AM, Alex Zavatone z...@mac.com wrote: Also, you can turn it off autosynthesis? How? That would be a big help for me to straighten out this iOS project where the original developers thought everything needed to be a java bean. As Graham said, go to the build settings and turn on the warning for “Implicit Synthesized Properties”. While you’re at it, turn on “Treat Warnings As Errors”. You’ll now get a compile error any time you forget to add an @synthesize directive (or implement explicit accessor methods.) —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On May 21, 2015, at 9:28 AM, Alex Zavatone z...@mac.com wrote: @synthesize thing = _thing; Which makes the internal and private ivar to be _thing while the property becomes thing. In my case, this helps to uncover where the original code is accessing the ivar as opposed to the property. I always use this naming convention. Not just for the reason you state, but because it makes it obvious which variables are ivars, i.e. which have object scope and which have local scope. (Yeah, you can make Xcode color them differently, but it’s not as obvious.) I highly recommend it. Now that I have a path forward and understand why things are what they are, this brings up the wonderful speed issue of how much slower is property access vs ivar access”. Yeah, I think we’ve had some vigorous debates about this topic in the past. And it’s not just about clock cycles, it’s also about code size — that blog post you linked to shows that ivar access is less than half as many instructions, plus the value can be saved in a register and reused. Code size significantly affects performance because of CPU’s limited instruction cache sizes. In most high level app code it probably doesn’t make much of a difference. Me, I tend to write lower-level code that does things like data storage and database queries, which are often seriously CPU-bound and where shaving off CPU cycles wherever possible does produce real improvements. (Plus, I’m lazy and it’s faster to type “_foo” than “self.foo”.) —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
Ahh. A little follow up. One area we all know about is that you can specialize the name of the property's ivar like so: @synthesize thing = _thing; Which makes the internal and private ivar to be _thing while the property becomes thing. In my case, this helps to uncover where the original code is accessing the ivar as opposed to the property. Instantly, as soon as you manually synthesize this way, the compiler points out every case in the class where the instance name is no longer valid. The problem behind this all is that if you use self.myThing, that's obviously a property, but if you use myThing, it's not visually obvious that you're directly accessing the ivar, not the property. When Xcode creates your properties with auto-synthesis, the compiler appears to create an ivar with the same name as property. Within the class itself, you can access self.myThing and myThing interchangeably and they will both end up with the same value as expected. Unfortunately, this makes it not visual no brainer which one you're accessing unless you pay attention. In my case, the wonderful original programmers created the instance variables and properties with the same name and frequently accessed both as if they were one and the same, resulting in some rather dense code. In an effort to refactor the code for readability and clarity, going through each class and making this change makes it painfully clear when the ivar's being accessed and when the property is. The reason why this matters is when trying to refactor code like this if you have ivars and properties declared with the same name, Xcode's refactoring fails if you try to refactor the property first. At least in my case, it does. In the effort to put some clarity into our large-ish classes, refactoring the ivars first means that I have to identify where they are used and using this @synthesize approach allows that. Now that I have a path forward and understand why things are what they are, this brings up the wonderful speed issue of how much slower is property access vs ivar access. Whichever you use depends on just how much you need speed vs encapsulation. Thankfully, that difference is summarized in charts at the end of the link below. https://www.bignerdranch.com/blog/should-i-use-a-property-or-an-instance-variable/ Again, thanks all who took their time to provide the backing information on this for me. Cheers, Alex Zavatone On May 21, 2015, at 9:45 AM, Alex Zavatone wrote: On May 20, 2015, at 7:16 PM, Michael David Crawford wrote: You could comment off their declarations in your header files, then have a look at which uses of them in your sources result in fatal compiler errors. Bingo. That will do it. Thanks much to everyone on this. It's certainly gotten me a little more in touch with the guts of this all. Alex Zavatone ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com This email sent to z...@mac.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
Have to correct a typo: On May 20, 2015, at 3:22 PM, Ken Thomases k...@codeweavers.com wrote: You are accessing a property if you use explicit message sending ([someObject someProperty] or [someObject setSomeProperty:someValue]) or if you use implicit message sending view dot syntax (someObject.someProperty). That should be via dot syntax, not view. -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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On May 20, 2015, at 1:04 PM, Alex Zavatone z...@mac.com wrote: Many times in the classes, an ivar is defined in the @interface of the class. Sometimes not. In the old days, before about 2006, the ivars had to be defined in the @interface. Nowadays it’s best to put them in the @implementation since they’re private to the implementation anyway. I always move them when updating old code. Now, I remember back in 2012 that I could access a property within an instance of the object without using self, but never knew if I was accessing the ivar or the property itself simply by looking at the object. It’s simple, really: • “foo” is a variable — either an ivar or some sort of C variable (local, parameter, static, global.) • “self.foo” is a reference to a property. It’s equivalent to “[self foo]”, or if it’s on the left-hand-side of an assignment it’s “[self setFoo: …]”. There’s no ambiguity at all. A property name _has to_ go after a “.”, with an object value beforehand. An instance variable _cannot_ go after a “.” (It’s possible to refer to an ivar as “self-foo” but that syntax is old-fashioned and discouraged AFAIK.) Ivars and properties have entirely different namespaces, so even if a property has a backing ivar (i.e. is synthesized) the names don’t have to relate to each other. If you don’t explicitly use @synthesize, then I believe the ivar names created by the compiler will be the property name prefixed with “_”. I’m strongly against auto-synthesis; I think it was a bad idea to add it to Clang. It may save you from having to type “@synthesize”, but it leads to a lot of confusion, as shown here, by blurring the distinction between properties and ivars and creating ivars out of nowhere. And it can cause bugs if you meant a property to have explicit get or set methods but forgot to implement them (or worse, misspelled them!) I always turn it off in the target settings of my projects. —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On May 20, 2015, at 3:04 PM, Alex Zavatone z...@mac.com wrote: Many times in the classes, an ivar is defined in the @interface of the class. Sometimes not. Then sometimes, the same name of the ivar is used in the class and defined as a property and @synthesized. Sometimes not. Now, I remember back in 2012 that I could access a property within an instance of the object without using self, but never knew if I was accessing the ivar or the property itself simply by looking at the object. You are accessing a property if you use explicit message sending ([someObject someProperty] or [someObject setSomeProperty:someValue]) or if you use implicit message sending view dot syntax (someObject.someProperty). Anything else is direct access to the instance variable. That can be a naked reference to the variable name in a method (e.g. someProperty or _someProperty), in which case it's implicitly a field of self, or it can be an explicit field access with the arrow operator (e.g. someObject-someProperty or someObject-_someProperty). In all of the above, someObject could be self or any other object pointer. Whether an instance variable has a leading underscore or not depends on exactly how the class was coded (whether and how the property was synthesized). The fact that the instance variable is named after the property it backs does not make it the property. Sure, if there was a 'self.' in front of the object instance, I knew it was the property. But in the case(s) I have today, I'm looking at inconsistently cased instance variables (some properties) and nowhere are any preceded by 'self.' within the object instance, yet in the debugger's variable pane, these variables that look like ivars are all under listed under self. Wha? Of course instance variables would be listed under self. Where else would they be listed? They are inside the object. That is, they are components of the object. So, they are listed under it hierarchically. The debugger will only ever list variables (including instance variables) in its variable list, never properties. Properties are methods. 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
there are good reasons to use properties that are backed by ivars, there are good reasons to use properties that aren't backed by anything, and there are good reasons to use ivars that are not properties. In my own code I started with nothing but ivars, but changed some of them to properties while neglecting to remove the original ivar. This leaves me somewhat in the same situation as you. As I refactor my own code I keep in mind each of the above three situations. Michael David Crawford, Consulting Software Engineer mdcrawf...@gmail.com http://www.warplife.com/mdc/ Available for Software Development in the Portland, Oregon Metropolitan Area. On Wed, May 20, 2015 at 1:42 PM, Ken Thomases k...@codeweavers.com wrote: Have to correct a typo: On May 20, 2015, at 3:22 PM, Ken Thomases k...@codeweavers.com wrote: You are accessing a property if you use explicit message sending ([someObject someProperty] or [someObject setSomeProperty:someValue]) or if you use implicit message sending view dot syntax (someObject.someProperty). That should be via dot syntax, not view. -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: https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com This email sent to mdcrawf...@gmail.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On May 20, 2015, at 1:04 PM, Alex Zavatone z...@mac.com wrote: In the code I've inherited, I've got the benefit of spending some time refactoring and have an interesting situation. Many times in the classes, an ivar is defined in the @interface of the class. Sometimes not. Then sometimes, the same name of the ivar is used in the class and defined as a property and @synthesized. Sometimes not. Sometimes, the ivars and properties start with lowercase letters as intended. Sometimes not. Now, I remember back in 2012 that I could access a property within an instance of the object without using self, but never knew if I was accessing the ivar or the property itself simply by looking at the object. Sure, if there was a 'self.' in front of the object instance, I knew it was the property. But in the case(s) I have today, I'm looking at inconsistently cased instance variables (some properties) and nowhere are any preceded by 'self.' within the object instance, yet in the debugger's variable pane, these variables that look like ivars are all under listed under self. Wha? Which are they, ivars or properties? I don't know. I can't tell. Is there any way to inspect an instance and tell if it is a property or an ivar if both the property and ivar have the same name? By default a property creates an ivar, the name of which depends slightly on if you are relying on auto-synthesis (in which case property foo creates ivar _foo) or explicit synthesis (in which case property foo creates ivar foo, which explains your “I didn’t need self” remembrance). Explicit synthesis can also provide a different ivar name, the only way to know what the ivar is named is to look for the @synthesize directives. Finally you can have a property that is not backed by an ivar at all, which would mean if you have property foo, you have -foo and -setFoo: accessors that don’t use the ivar at all (assuming you don’t also have an @synthesize; in that case it is probably just a bug). Fun times, fun times. Thanks in advance. - Alex Zavatone ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/david.duncan%40apple.com This email sent to david.dun...@apple.com -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On May 20, 2015, at 4:08 PM, Eric Wing ewmail...@gmail.com wrote: You could use the Objective-C runtime to find out which things are properties. You could, but isn’t it a lot easier to just look at the character before the name and check whether it’s a “.”? —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On 5/20/15, Jens Alfke j...@mooseyard.com wrote: On May 20, 2015, at 4:57 PM, Eric Wing ewmail...@gmail.com wrote: It depends on how pedantic you want to be. As little as possible, honestly. Did you go back and read the original question? The OP is having trouble with basic property-vs-ivar distinctions, and dropping a whole bunch of science on him isn't going to do anything but increase confusion. --Jens I didn't intend to be unhelpful. I interpreted the original question as a static analysis problem where the existing tools aren't sufficient in doing the analysis for him. Dumping a list of all declared properties so he can do additional cross-references himself to help sort out the codebase didn't seem like an a completely unhelpful idea to me. (And come to think of it, grep for @property would do the same as long as the code base isn't dynamically creating properties.) -Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
Which are they, ivars or properties? I don't know. I can't tell. Is there any way to inspect an instance and tell if it is a property or an ivar if both the property and ivar have the same name? Fun times, fun times. You could use the Objective-C runtime to find out which things are properties. Look for functions like: objc_property_t * class_copyPropertyList ( Class cls, unsigned int *outCount ); ivars that are not properties will not show up as properties, so you can cross-reference these with a master list you keep. -Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
You could comment off their declarations in your header files, then have a look at which uses of them in your sources result in fatal compiler errors. (Comment off just one at a time.) Michael David Crawford, Consulting Software Engineer mdcrawf...@gmail.com http://www.warplife.com/mdc/ Available for Software Development in the Portland, Oregon Metropolitan Area. On Wed, May 20, 2015 at 4:08 PM, Eric Wing ewmail...@gmail.com wrote: Which are they, ivars or properties? I don't know. I can't tell. Is there any way to inspect an instance and tell if it is a property or an ivar if both the property and ivar have the same name? Fun times, fun times. You could use the Objective-C runtime to find out which things are properties. Look for functions like: objc_property_t * class_copyPropertyList ( Class cls, unsigned int *outCount ); ivars that are not properties will not show up as properties, so you can cross-reference these with a master list you keep. -Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com This email sent to mdcrawf...@gmail.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On 21 May 2015, at 6:50 am, Michael David Crawford mdcrawf...@gmail.com wrote: In my own code I started with nothing but ivars, but changed some of them to properties while neglecting to remove the original ivar. This leaves me somewhat in the same situation as you. Nothing wrong with that, AS LONG as you remember to add the @synthesize foo = myOriginalIvar in your implementation. Problem is, it’s not a compile-time error if you forget. It might not even be a runtime error, but it’s very likely a bug anyway, because when you think you’re manipulating myOriginalIvar , in fact it’s manipulating a hidden _foo ivar. At its most benign, this is just a minor waste of space for the myOriginalIvar storage, but if code (and legacy code is quite likely to do this) is sometimes accessing the ivar directly, and sometimes through the property, you have a very, very definite and insidious bug. Frankly, (and I have said this before more than once) the design of autosynthesizing properties, added as it was later to properties themselves, is a nasty way to shoot yourself in the foot and not even realise it. Caught me out numerous times. You can enable the warning CLANG_WARN_OBJC_MISSING_PROPERTY_SYNTHESIS (“Implicit Synthesized Properties” in build settings) to at least be told when you pulled the trigger. —Graham ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On May 20, 2015, at 4:57 PM, Eric Wing ewmail...@gmail.com wrote: It depends on how pedantic you want to be. As little as possible, honestly. Did you go back and read the original question? The OP is having trouble with basic property-vs-ivar distinctions, and dropping a whole bunch of science on him isn’t going to do anything but increase confusion. —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
If you have so many ivars, or so many properties that it's a lot of work to figure out which is which, quite likely you're doing something wrong. Now you're already refactoring your code, so you're doing something right there. It is quite common that well-done refactoring reduces the numbers of lines of code. Michael David Crawford, Consulting Software Engineer mdcrawf...@gmail.com http://www.warplife.com/mdc/ Available for Software Development in the Portland, Oregon Metropolitan Area. On Wed, May 20, 2015 at 4:17 PM, Jens Alfke j...@mooseyard.com wrote: On May 20, 2015, at 4:08 PM, Eric Wing ewmail...@gmail.com wrote: You could use the Objective-C runtime to find out which things are properties. You could, but isn't it a lot easier to just look at the character before the name and check whether it's a .? --Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com This email sent to mdcrawf...@gmail.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On 5/20/15, Jens Alfke j...@mooseyard.com wrote: On May 20, 2015, at 4:08 PM, Eric Wing ewmail...@gmail.com wrote: You could use the Objective-C runtime to find out which things are properties. You could, but isn't it a lot easier to just look at the character before the name and check whether it's a .? --Jens It depends on how pedantic you want to be. For example, if you implemented your own setter/getter methods, the dot syntax I believe still works even though these technically aren't properties. The Obj-C runtime functions I'm describing makes a harder distinction and will only list things declared with @property. -Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On May 20, 2015, at 6:57 PM, Eric Wing ewmail...@gmail.com wrote: On 5/20/15, Jens Alfke j...@mooseyard.com wrote: On May 20, 2015, at 4:08 PM, Eric Wing ewmail...@gmail.com wrote: You could use the Objective-C runtime to find out which things are properties. You could, but isn't it a lot easier to just look at the character before the name and check whether it's a .? --Jens It depends on how pedantic you want to be. For example, if you implemented your own setter/getter methods, the dot syntax I believe still works even though these technically aren't properties. The Obj-C runtime functions I'm describing makes a harder distinction and will only list things declared with @property. Properties existed long before there was @property. The distinction you're referring to is the difference between an informal property and a declared property. If you have implemented a getter, you have implemented a property. Yes, only declared properties can be introspected using the runtime. 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
