Path: utzoo!utgpu!attcan!uunet!tektronix!tekcrl!tekgvs!toma
From: toma@tekgvs.GVS.TEK.COM (Tom Almy)
Newsgroups: comp.lang.smalltalk
Subject: Re: Duplication of instance variables in subclasses
Message-ID: <4379@tekgvs.GVS.TEK.COM>
Date: 15 Dec 88 15:54:51 GMT
References: <1397@aucs.UUCP> <5818@thorin.cs.unc.edu> <1445@aucs.UUCP>
Reply-To: toma@tekgvs.GVS.TEK.COM (Tom Almy)
Distribution: na
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 23

In article <1445@aucs.UUCP> 831059l@aucs.UUCP (Langlois) writes:
>[...] I suppose I wanted to keep my classes for doing simulations all
>in the same place (class and subclasses) because I didn't like the idea
>of having the classes spread throughout the system. When you make a change
>you have to possibly remember everything you've done like at a subclass to
>SortedCollection to implement a queue with statistics. [...]

This points out a deficiency of Smalltalk/V (which I am assuming Mr.
Langlois is using) compared to Smalltalk-80.  Smalltalk-80 has class
categories, with every class being assigned a cateThis becomes the
first level of selection in the browser.  So you can write an application
which has new subclasses of many existing classes, yet these new classes
appear in the browser within a single category (presumably with your
application name) rather than spread out in the class heirarchy.  The
existance of projects (with separately maintained change logs which can
be browsed) is another big gain.

Adding categories and modifying the browser shouldn't be too big a job,
and it sure would help Smalltalk/V.

Tom Almy
toma@tekgvs.tek.com
Standard Disclaimers Apply