Hi guys!

There are a few other answers to these questions already, but here is some more.

--- James Stark <james_stark03 at hotmail.com> wrote:
> I thought I would just ask this smalltalk list a couple of questions - I am 
> new to smalltalk and this list has been highly recommended in solving most 
> smalltalk problems - guess its because all of you are smalltalk gods or 
> something... anyways... here it goes.

And because we are such a nice bunch of people! And I am no god, but sure, we have a few of those
around for the trickier questions... ;-)

> I have a record subclass declared as follows:
> 
> Object subclass: #RECORD - I have various methods for this.
>
> I want to make an array of records - so its one array that stores of type 
> records - which I have defined
> 
> I have tried the following:
> 
> OrderedCollection subclass: #People

Ok, hold on here. Having taught OO etc quite a lot, I think I see two beginner mistakes here - but
hey - that is ok - since you are a beginner! :-)

The first one is that class names should always be in singular (well, 99.9% of the time). You
should always be able to say "a/an <classname>" like for example "a Collection", or "a String".
You can say "a People" of course but that would imply that an instance of your class represents "a
People" like in "this instance here represents the Swedes and this other instance I have in my
other hand represents the Brits". (instance variables would then be "population size", "primary
language" etc)

I am guessing that perhaps the class name "Person" id more in line with what you want, thus
implying that one instance represents one single person with instance variables like "name", "age"
and "sex".

The next mistake is overuse of inheritance and especially the mistake of trying to inherit from a
Collection class. Normally you only do that when you want to create a new KIND of collection
class, and that doesn't happen often - most Smalltalkers have never done that.

There is a very simple trick you should use whenever you think that inheritance might be a good
idea - the "is a kind of"-trick. The trick is that normally you should be able to say "A is a kind
of B" (substitute A and B for subclass and superclass respectively). Thus "OrderedCollection is a
kind of SequencableCollection". Sounds correct.

If the test sounds wrong, like in for example "Animal is a kind of Dog" you can try to switch A
for B and listen to that instead - "Dog is a kind of Animal". Ah! Much better which implies that a
subclass called Dog with Animal as the superclass would probably work.

Sometimes it just doesn't sound right whichever way you try like in "Parrot is a kind of Dog"...
Nope. Ok, "Dog is a kind of Parrot"... Wrong again. This is a common situation. Since you feel
that Parrot and Dog have things in common they ought to inherit from each other in some way...
Right? Yes. Normally you can then try this: "Dog is a kind of X" and "Parrot is a kind of X". Now
find a value for X that would work for both. Animal perhaps? This would give us "Dog is a kind of
Animal" and "Parrot is a kind of Animal" which both sound ok. So, the classes have a common
ancestor which is why they have things in common.

If you check out the inheritance hierarchy for the class Collection you will indeed find a lot of
subclasses but they still all should hold true to the test mentioned.

Lets try it then: "Person is a kind of OrderedCollection". No, sounds pretty weird. Of course, I
could be viewed as a collection of cells but in a specific order? ;-) No.

It almost sounded good when the class name was "People" but that class name was probably not
"correct" (my guess though).

So, what is the answer? Well, as Ned Konz pointed out - when inheritance is not the answer almost
always "composition" is!

This means that when it is not suitable to create a more complex object by reuse through
inheritance we should instead create the complex object by combining "parts" into a new "whole".
Like we do in real life when we "build" something. In Smalltalk we do composition by adding
instance variables to a class and making sure that those variables hold the "parts" (the other
objects) that we want our instance to "consist of" or "be built of".

Actually, composition is in most ways the much more natural way of doing reuse. Inheritance is
more like creating a new blueprint by taking an already existing blueprint and extending it with
new lines - not easy, hard to find an existing blueprint that fits, and often very complex.

So, back to your problem. I would guess that you should create a class Person (or PersonRecord
might be better, implying that the object is a record of a person and not really the person
himself/herself) that subclasses either directly from Object or perhaps from the class Record you
mentioned.

Then you want to hold onto the instances of Person using for example an instance of
OrderedCollection. That instance in turn should probably be held in an instance variable of a
"larger" object like perhaps a "PersonRegistry" or a "Rolodex".

Every object in Smalltalk is a part of another larger object. There is only one exception (I
think), but I will drop that for now. :-)

Anyway, I hope this was of some help, I just got an urge to write! :-) If you want more specific
help, just ask.

regards, Göran

=====
Göran Hultgren, goran.hultgren at bluefish.se
GSM: +46 70 3933950, http://www.bluefish.se
"Department of Redundancy department." -- ThinkGeek

__________________________________________________
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com