A big teacher wish

Richard A. O'Keefe ok at cs.otago.ac.nz
Wed Nov 27 23:56:49 UTC 2002


Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
	I see your point but I partly disagree.  As soon as you have
	singleton, and you want to teach one inch of design you have to
	explain the difference.
	
I don't understand this.  The difference between *what* and *what else*?
Some context is missing here.  I don't know what "one inch of design"
might be, nor do I see any connection with "singleton".  (As Vlissides
points out, "singleton" is a misnomer.  The pattern isn't about ensuring
that there is exactly one object, but about ensuring that the class is
in control of the number.  "SINGLETON's responsibilities imply that it
it _owns_ the instance it creates ... in contrast to other creational
patterns." (Pattern Hatcing, p62.  He talks of subclassing a "singleton"
class (p69, for example), which makes no sense if only one instance can
exist.  But above all, his "User" class "ensures that only one instance
is created" *per active user*.  (p49.)

I really don't see any salient difference here between classes that
are used as singletons (or generalised "singletons") and classes that
are not.

When you have a Singleton, you usually *don't* create its instance
right off.  You wait until it's needed, and *then* you create it.
So there are class variables which exist as soon as the class is
loaded, and there are instance variables which come into existence
when the instance (or instances, in the case of quasi-Singletons
like Squeak's Character) is (or are) created.

I can honestly say that one concept my students have *never* had
trouble with in Smalltalk is instance variables -vs- class variables.
And I don't just mean the recent students who already met the same
ideas in Java.  (They've even met the phrase "instance variable"
before.)

	For me classVariables are shared between a class and its
	metaclass (instances and their class) and this point is more
	important that regarding inheritance because I refuse to access
	variables of superclasses directly.

It only makes sense to call them 'shared' variables if
(a) they are the ONLY kind of variable that is shared, or
(b) they can't exist without being shared, or
(c) their sharedness is the most salient thing about them.
That is, somehow sharedness has to be a distinguishing
characteristic or a defining characteristic.

None of these is true.

(a) Global variables are ALSO shared, with absolutely everything.
    Variables in pool dictionaries are shared by all the classes
    that bind to them, and all the instances of those classes.
    Even instance variables are shared:  by every method activation.
    More: even method arguments are shared (by block contexts that
    were activated inside the corresponding method activation).
    There isn't ANY kind of variable in Smalltalk that cannot be
    or is not normally shared with *something*.

(b) Class variables don't HAVE to be shared.  In fact most of the
    class variables I make (which isn't that many in the first place)
    AREN'T shared.  That is, the scope rules of Smalltalk say that
    they _could_ be accessed by instances and subclasses, but it so
    happens that they are not.  If the scope of a class variable was
    just the metaclass, then you could write access methods in the
    metaclass.  For the obvious 'lazy initialisation' reasons, I	
    normally do write an accessor for reading class variables.  For
    the obvious 'sanity check' reasons, I normally do write an
    accessor for writing class variables, if I want them mutable.
    If the rules of Squeak were changed tomorrow so that class
    variables didn't have shared scope, very little of what I've
    written would need to be changed at all.  My class variables
    would not be shared variables any more, but they would still be
    CLASS variables, and I would still have exactly the same design
    reasons for creating them.

(c) What matters is *lifetime*. I hate to say it, but if someone
    understands the word 'static' (which goes back to PL/I's STATIC,
    AUTOMATIC, ALLOCATED, or CONTROLLED distinction), then 'static' in
    Java is just about perfect for conveying the most salient fact:
    class variables exist as long as the class does.

    CLASS VARIABLES ARE WHERE YOU PUT STUFF THAT SHOULD PERSIST AS LONG
    AS THE CLASS DOES.

    That's the whole story about class variables.  If you have
    understood the connection between the lifetime of the class object
    and the lifetime of its class variables, you have understood the
    most important thing about class variables.

So I really *cannot* see the point in a name change which goes
out of its way to conceal the most important design-relevant fact
about class variables and to stress the least design-relevant fact
about them.

	> "class variables" are things that belong to classes.
	> "instance variables" are things that belong to instances.
	> It doesn't get much clearer than that.
	
	But this is not clear because from instance methods I can access
	classVariables which when I teach that instances variables are
	all private is a violation of the rule.

I am having some trouble understanding that.  What rule?

There isn't any rule that instance variables are all private.
Never has been.  In C++ jargon (actually, I think it goes back to
Simula 67, but my Simula 67 manual and books predate the introduction
of the HIDDEN and PROTECTED keywords to Simula) instance variables
are 'protected', not 'private'.

A rule about instance variables being private is not violated
if class variables (which are not instance variables) are not private.

	So classVariables are stuff that belongs to classes BUT SHARED
	among instances and classes.

As explained above at length, this is irrelevant.
You could give the students another (incorrect) rule that
class variables are private to classes.
That would affect the way that they _accessed_ class variables,
but it would in no way affect the REASONS for having class variables,
which have to do with the difference between instance lifetime
and class lifetime.

You see, the names 'instance variable' and 'class variable' have
nothing whatsoever to do with scope, and everything to do with lifetime.
My students are taught the distinction as a lifetime distinction
and have no trouble with the concepts or the names.

If you try to explain class variables -vs- instance variables in
terms of scope, OF COURSE it's not going to work.

	and cannot access do not work with class variables.

I can't parse that.

	I'm not clear but I'm sure you see my point.

At the risk of being rude, this is how I understand you:

    <<Whether something should be a class variable or an instance
      variable is a matter of whether it should have the same lifetime
      as the class or the same lifetime as an instance.
      But I want to explain this in terms of scope, not lifetime.
      So I want the phrase 'class variable' changed to suit the way
      I explain this, and I want the new name to stress an aspect
      of class variables that I don't like and wish didn't exist
      and is in any case common to all Smalltalk variables.>>

Yes, it's a caricature.  Yes, it's not a verbatim quotation.
But it _is_ an honest description of how I understand you here,
and that's what I'm saying NO to.




More information about the Squeak-dev mailing list