🚀 go-pugleaf

Though I'm just a novice in Objective-C I have run across a case where
class variables would simplify things.

In answer to your first two questions, I believe class variables would
be useful and that case one would be the better system.

>** 1 -- each subclass has its own copy of its parent's class variables
> 
>   2 -- all subclasses share a single copy of their parent's class variables

  I think at run time each subclass should be thought of as distinct
from its parent and thus have it's own variables.  A programmer
shouldn't have to worry about changes made to the class variables of a
parent class or sibling class effecting its own class variables.
Unless someone can give examples why this ability would be needed then
to minimize side effects system one seems adequate.

  A hypothetical use that makes me favor class variables is as
follows:

  Suppose the first instantiation of a class "PriorityQ" puts its id
into a class variable call "defaultQ".  Subsequent calls to the class
"PriorityQ" using the method "+newORdefault" would then return the id
contained in "defaultQ" or a new id if the "defaultQ" variable is nil.
If (using another method) the variable "defaultQ" was changed then any
new invocations of the "+newORdefault" method would return the new id
in the class variable "defaultQ".

  What bothers me about this example is that (I think) NeXT has produced
a similar effect in their "Conductor" class (which can be found within
the MusicKit).  If class variables don't exist in Objective C then I'm
not sure how they did this.

  I hope I haven't over looked something due to my limited experience
with Objective C.

Cheers,

  -- Richard

-------------------------------------------------------------------------------
 "Programs were devised whose `thinking' was to human thinking as a
 slinky flipping end over end down a staircase is to human locomotion."
							-- D.R. Hoffstadter
-------------------------------------------------------------------------------
Richard Myers / 6 Exeter / Irvine, CA 92715 / 714-854-4410 / rmyers@ics.uci.edu

-- 
-------------------------------------------------------------------------------
 "Programs were devised whose `thinking' was to human thinking as a
 slinky flipping end over end down a staircase is to human locomotion."
							-- D.R. Hoffstadter

    For the simple cases, class variables can be simulated in Objective-C
with static variables declared in the same file that the class is declared.
This is limited in that superclasses or subclasses of the class cannot access
the class variables directly, but instead need to call methods in
defining class.  Actually, from a modularity standpoint, that's probably not
too bad, but it goes against the Objective C philosophy, such as it is.

    For more complicated needs, I think the suggestion that each subclass have
its own copy of its parent's class variables is the correct one, since it's
easy to do the other case (every subclass accessing the same, single copy of
their parent's class variables) with statics or globals.  I came across the
need for class variables when I needed to associate an event-handler object
with every subclass of a given class - with the correct semantics, a single
class variable, in the parent class, would do the job.  

   I solved the problem in the obvious way, with an association list, where I
associated the factory object with the event-handler object.  Actually, I
implemented the general case of property lists, which associate name/property
pairs with arbitrary objects.   Then the property lists' name/property/value
implement class variables as class-object/class-var-name/class-var-value. 
[Alternatively, property lists names can be the variable names and properties
can be class objects; it depends on the implementation as to which is better.] 

   As far as I know, there are no conceptual reasons why class variables
haven't been implemented in Objective-C yet; it just seems that no one has
gotten around to it.  In point of fact, there are already a fixed number of
class variables already stored per class (I'm refering to the fact that
each factory object has an "isa" class variable, a "clsSuper" class variable
which points at the factory object of the superclass, a "clsName" which
is a string, "clsTypes" which describes the type instance variables of the
class, as well as size information of instances, and a dispatch table,
both of which can be considered class variables as well).  All that's needed
is some syntax for adding to this existing structure of class variables on
a per class basis.

-- 
ARPA:       Dean.Rubine@CS.CMU.EDU	
PHONE:	    412-268-2613		[ Free if you call from work ]
US MAIL:    Computer Science Dept / Carnegie Mellon U / Pittsburgh PA 15213
DISCLAIMER: My employer wishes I would stop posting and do some work.

I first replied to the author of the original article, but this
is the place for discussion:

rmyers@ics.uci.edu (Richard E. Myers) writes:

>In answer to your first two questions, I believe class variables would
>be useful and that case one would be the better system.

>>** 1 -- each subclass has its own copy of its parent's class variables
>> 
>>   2 -- all subclasses share a single copy of their parent's class variables

I would prefer case 2!

>  I think at run time each subclass should be thought of as distinct
>from its parent and thus have it's own variables...

Inheritance is just an implementation technique to minimize redundant code.
At run time there is no subclasses or superclasses, just objects (and classes
that I think of as objects too). If you have class hierarchy (bad example):

Picture
 |      \
TextPic GeometricPic

you want them to share the same Printer. etc etc.

Note that you can simulate class variables with the static mechanism.
Since every class is declared in it's own file a static works like
a class variable, with the restriction that it's not inherited. If
you supply the class with a factory method that return the static
you can use it in subclasses too. |+cPrinter| and |+cPrinter: aPrinter|.

--
      +-------------------------+--------------------------+
      |  Kenneth Persson        |  email: kenneth@eb.se    |
      |  EB Signal AB, Sweden   |  voice: +46 8 726 2267   |
      +-------------------------+--------------------------+

With regard to the question about what kind of class variables people
want, here is a comment from another community.

> 1 -- each subclass has its own copy of its parent's class variables
> 
> 2 -- all subclasses share a single copy of their parent's class variables

In CLOS, we did 2.  It seemed natural, and it works well.  But, there
are plenty of cases where what users want is 1.  Fortunately, in CLOS,
the Metaobject Protocol makes it easy for users to add this kind of
class variable themeselves.  But, given that you don't have a Metaobject
Protocol, I would say do both 1 and 2.

In article <GREGOR.90Oct14231438@spade.parc.xerox.com> gregor@parc.xerox.com (Gregor Kiczales) writes:
>
>With regard to the question about what kind of class variables people
>want, here is a comment from another community.
>
>> 1 -- each subclass has its own copy of its parent's class variables
>> 
>> 2 -- all subclasses share a single copy of their parent's class variables

I think this arguement is beginning to get silly.  If you do #2, you can 
always do #1 by adding a new variable and overridding all methods that affect
the variable in question.  If you do #1, there is no way to do #2.  
Therefore, #2 should be done.
-- 
Michael Rutman				|	moose@svc.portal.com
Cubist					|	makes me a NeXT programmer
Software Ventures			|	That's in Berkeley
smile, you're on standard disclaimer	|	<fill in with cute saying>

The choices:

 #1 -- each subclass has its own copy of its parent's class variables
 
 #2 -- all subclasses share a single copy of their parent's class variables

In article <1990Oct15.185718.8342@svc.portal.com> moose@svc.portal.com writes:
>I think this arguement is beginning to get silly.  If you do #2, you can 
>always do #1 by adding a new variable and overridding all methods that affect
>the variable in question.  If you do #1, there is no way to do #2.  
>Therefore, #2 should be done.
>Michael Rutman

     Hmmm.  I too thought the argument was silly, but I reached the opposite
conclusion.  I thought: #2 can be perfectly simulated with global (or static)
variables, while #1 gives some new functionality.  I already gave an example in
a previous post: #2 allows an event handler to be associated with each subclass
of View, just by declaring a class variable "eventHandler" in the View class
(and presumably defining some factory methods in View which reference
"eventHandler").  

     As I read Mr. Rutman's reasoning, given choice #2, all I'd have to do to
associate an event handler with every subclass of View is declare a variable
(class or static) in EVERY subclass, and provide appropriate methods in EVERY
subclass.  Yeech.  Note that I'd likely be repeating the same code in every
subclass - this seems contrary to the object-oriented paradigm, in which
inheritance is supposed to be used to avoid such of repetition of code.  This
problem doesn't come up with class variables of kind #1.    

-- 
ARPA:       Dean.Rubine@CS.CMU.EDU	
PHONE:	    412-268-2613		[ Free if you call from work ]
US MAIL:    Computer Science Dept / Carnegie Mellon U / Pittsburgh PA 15213
DISCLAIMER: My employer wishes I would stop posting and do some work.

In article <10777@pt.cs.cmu.edu> dandb@k.gp.cs.cmu.edu (Dean Rubine) writes:
[let's leave these choices up for all future posts]
The choices:

 #1 -- each subclass has its own copy of its parent's class variables
 
 #2 -- all subclasses share a single copy of their parent's class variables

>
>     As I read Mr. Rutman's reasoning, given choice #2, all I'd have to do to
>associate an event handler with every subclass of View is declare a variable
>(class or static) in EVERY subclass, and provide appropriate methods in EVERY
>subclass.  Yeech.  Note that I'd likely be repeating the same code in every
>subclass - this seems contrary to the object-oriented paradigm, in which
>inheritance is supposed to be used to avoid such of repetition of code.  This
>problem doesn't come up with class variables of kind #1.    

A bit of code is going to follow.


int myGlobal;

+ saveMyGlobal:(int)number
{
	myGlobal = number;
	return self;
}

+ (int)getMyGlobal
{
	return myGlobal;
}

now, all references to myGlobal are through these lovely factory methods.
(Instance methods would work fine, but who cares :->)

Subclass now.
We want to override myGlobal with

int myOwnGlobal;

We override saveMyGlobal and getMyGlobal with

+ saveMyGlobal:(int)number
{
	myOwnGlobal = number;
	return self;
}

+ (int)getMyGlobal	{return myOwnGlobal;}

We could even go so far as to have something like

+ saveMyGlobal:(int)number
{
	myGlobal -= myOwnGlobal;	//to remove the old value
	myGlobal += number;		//keep a total for all subclasses
	myOwnGlobal = number;
	return self;
}

Now, show me how to do that in #1, a case where I actually want the subclass
to have its own copy of the variable and a copy of the superclasses variable.
-- 
Michael Rutman				|	moose@svc.portal.com
Cubist					|	makes me a NeXT programmer
Software Ventures			|	That's in Berkeley
smile, you're on standard disclaimer	|	<fill in with cute saying>