From: riks@ogicse.ogi.edu (Rik Fischer Smoody)
Newsgroups: comp.lang.smalltalk
Subject: Re: Classes as a dirty trick to get globals.
Date: 14 Aug 92 20:07:03 GMT
Article-I.D.: ogicse.41397
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR

In article <1992Aug14.063858.5508@cs.tu-berlin.de> muhr@opal.cs.tu-berlin.de (Thomas Muhr) writes:
>I would not call it a "dirty" trick, but as one solution to overcome
I say "dirty trick" with a clear recognition that most dirty tricks
    work, at least for the purposes of their perpetrator.
>the difficulties in accessing variables which are shared between
>different branches in the class hierarchy. It is better than using
>global variables which are hard to maintain (usually they are prefixed
>by an unambigous string) in the global Smalltalk dictionary. Pool
>dictionaries also have their disadvantages (clash between local
>variables and pool variables). Maybe an export/import mechanism would
>provide a better solution. What is your solution?
My preference is for the "Global" or at least "properly advertised"
    object which is instantiated from the correct class
    of object and installed in the "right" place (assuming we can find a
    "right" place for it.  
The term "Global"  becomes obsolete as soon as you drop the notion of
    "my image is the entire universe".
Installing a unique global object as a class does put the object in a
    "right" place.  It also makes use of the mechanism which is already
    present in the programming environment to accomplish that goal. 
    My objection is that it has no business BEING a class unless it
    expects to be instantiated.
    If the programming environment made it almost automatic to maintain
	distinguished SortedCollections in the "global" dictionary known
	as Smalltalk, we would see several examples of SortedCollections
	installed there, without having elements added to them.  Their
	methodDictionary's would be used as Classes' are now.

Naming is important, especially for us humans to get mnemonic value.
    I personally do not like contrived names that prepend the company of creation,
    the current author's name, the place in some hierarchy, nor short letters
    to grandmother.  Naming is an art.  Practice it well.
>
>I do not think that a static class structure is documentation in
>itself, but should always be clarified by commentaries. 
Agreed.  That is a MINIMAL requirement.  
I propose a more formal maintainence of "why is this here" and "what
must it do" info.
>>Future engineers might decide that there needs to be another "instance"
>>    of this globally known object.  I have seen an example (identity
>>    of perpetrators withheld to protect the unconvicted) where the
>>    second instance was implmented as a sub-class, with numerous methods
>>    over-written to access a different class variable.
>I do not understand the above. What is meant by "second instance impl.
>as subclass"?
Let's suppose that they implemented a class CheckBook.  On the assumption
that you only have ONE CheckBook, they put all the behavior in the class.
It had class variables #Balance and #CheckNumber.
Later, a second bank account was opened (or they got married?) and a
second CheckBook was needed.  A subclass CheckBookB was created, with
class variables #BalanceB and #CheckNumberB.  All methods that accessed
either variable were over-written.

I think there should have been a class CheckBook with an instance
installed as #MyCheckBook (or something).  The second instance
could then simply be instantiated and installed as #MyCheckBookB.

The extra maintainence hassle of installing the first one would have been
repaid many times over with the second instantiation.
>>
>>On Smalltalk V/MAC, a quick scan found (Color MTrap Compiler and LCompiler )
>Compiler & LCompiler aren't merely holders of global variables, they
>have a lot of hidden code, thou.
I checked: while there is hidden code on the Class side, there were not
even any messages in the Instance side.  The method dictionary was empty.

In the world as we know it, use the dirty tricks with care and pwoer.
But in the next Object-Comprised world, let us be more careful that
the programming environment helps us to implement clean designs cleanly.

-Rik
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU