Re: NSDate value set in one method, vanishes when accessed from another
Re: NSDate value set in one method, vanishes when accessed from another
- Subject: Re: NSDate value set in one method, vanishes when accessed from another
- From: Uli Kusterer <email@hidden>
- Date: Sun, 22 Apr 2012 14:12:39 +0200
On 19.04.2012, at 20:02, Alex Zavatone wrote:
> Make it a property so that it doesn't go away, but exists for the whole class.
>
> Check out how to define a property. There are lots of examples around.
That's wrong. There are no properties on classes. There are only properties on instances of classes.
It helps to think of a class as a blueprint. When you create a new object of that class (called an "instance" by geeks), you actually build, say, a radio according to those blueprints. When you destroy the radio because you no longer need it (OK, this is where the analogy becomes more violent and wasteful than I intended), the blueprint still exists, and you can create a new instance according to these plans, or several at the same time.
Now, the blueprint (i.e. the @interface ... @end and @implementation ... @end in your source code) say that a radio has a "current frequency" property, a "volume" property, maybe even a "date" property if it has a built-in clock. But that *does not* mean that the *class* has a current frequency, volume or date/time.
When you create a new radio from the blueprints, it will have those things. When you set the clock on your radio in San Francisco, it will not change the date on my radio in Munich. Each object/instance/radio gets its own property.
OTOH, when you create a global variable like your fromDate, there is only one for your entire program. If you change the clock in San Francisco to be correct, it will suddenly be wrong for me in Munich.
Now that's not necessarily wrong, if you intended to build a radio with a "San Francisco Local Time" clock, mind you. It just depends on what you are actually trying to do ... ?
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden