Re: Scoping of functions
Re: Scoping of functions
- Subject: Re: Scoping of functions
- From: Bill Bumgarner <email@hidden>
- Date: Wed, 29 May 2002 19:07:33 -0400
[As there seems to be some confusion here-- entirely likely it is mine] My
interpretation of 'class variable' is a variable that works exactly like
an instance variable but is a part of the class object [really, the class
meta object in ObjC]. As noted, ObjC does not have class variables.
Given that assumption, If I declare...
static int foo;
... in Thingamahover.m and declare...
static int foo;
... in SubThingamahover.m, then the two foo are not the same. Static
variables, in this context, are only accessible within the scope of the
file [module].
This is very close-- but not identical-- to the behavior of a class
variable. As you note, it does not do ineritance-- i.e. 'foo' is not
acting as an instance variable of the class object. However, this is
trivial to work around:
- declare the 'class' variable in the most abstract super appropriate
- provide getter/setter methods in that class
- all subclasses should access the variable through the getter/setter
methods
The difference is this: If I declare an instance variable of the same
name in a subclass, the compiler complains. In the above example, static
variables in different files can have the same name since the variable is
not advertised outside of the scope of that file [at link time].
In any case-- Ondra's statement that this behavior is generally exactly
what one wants certainly has been the case in my experience, as well.
b.bum
On Wednesday, May 29, 2002, at 06:54 PM, Ondra Cada wrote:
On Thursday, May 30, 2002, at 12:00 , Bill Bumgarner wrote:
As long as you stick to a general rule of 'one class per .h or .m', then
static variables as shown above are, effectively, class variables
Not really. Statics are still globals; class variables would belong to a
particular class. Just make a subclass of your Thingamahover -- it would
share the values contents with its superclass.
I haste to add that quite often it is exactly what you *wanted*, whilst
true class variables -- one specific for each class, non-shared with any
other regardless inheritance -- would not do what you need.
In those rare cases when you *need* class variables, the common approach
is to define a global NSDictionary, use class ids (as NSValues) for keys,
and store real values this way.
---
Ondra Cada
OCSoftware: email@hidden http://www.ocs.cz
2K Development: email@hidden http://www.2kdevelopment.cz
private email@hidden http://www.ocs.cz/oc
b.bum
Do the voices in my head bother you?
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.