help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] Which Class do I use?


From: Stefan Schmiedl
Subject: Re: [Help-smalltalk] Which Class do I use?
Date: Sun, 10 Jan 2010 20:41:28 +0100

On Sun, 10 Jan 2010 09:52:42 -0700 (MST)
Duke Normandin <address@hidden> wrote:

> Or more specifically, "How does one *start* an OOP/GST program?
> 
> My understanding so far of OOP - which, to me, means GST - is that
> there exists the following general structure:
> 
> Genesis Object (God)
> |
> +--ClassA  (which is an object having its origin in God)
> |      |
> |      + ---- ClassA.InstanceOf1 (which is an object)
> |      |               |
> |      |               +--feature1 (which is an object)
> |      |               |
> |      |               +--message1 (that feature1 understands)
> |      |               |
> |      |               +--feature2
> |      |               |
> |      |               +--message2
> |      |
> |      |
> |      +---- ClassA.InstanceOf2
> |
> +--ClassB
> |
> +--ClassC
> |
> and the list goes on, and on, and on, and on... ;)

This looks suspicously like you see a class as a collection
of instances. A class is more like a factory. True, it does
"keep track" of its products (allInstances), but this is
not really something you would need right now.

Everything is an object, every object has a class.
You can talk to your system asking objects for their class,
starting simple and getting fancy:

GNU Smalltalk ready

st> 1 class
SmallInteger
st> 'a' class
String
st> String class
String class
st> String class class
Metaclass
st> String class class class
Metaclass class
st> String class class class class
Metaclass
st> 

GNU Smalltalk user confused :-)

What does this tell you? "String" instances are made by factory
"String class". This "String class" factory of strings itself is
made by a factory "Metaclass", which in turn is a factory made by
"Metaclass class", and so on.

Ok, but what does this mean? Not so much, actually, as you now
only know "who made the factory that made the factory that made
my object", but you still don't know the capabilities of the object,
i.e. what would happen if you send a message to it.

When an object receives a message, it looks it up in its
so-called "method dictionary". As with any mass production system,
all objects made by a given factory show the same behavior, so
it makes sense to store that behavior only once, i.e. in the
object's class. If a method implementing the message is found
there, it is executed and all is well.

st> 1 class
SmallInteger
st> 1 class methodDictionary size
38

So 1 can answer to the 38 messages implemented in SmallInteger

If no matching method is found the method dictionary,
the method dictionary of the superclass is consulted, which here
has 54 methods ... and so on.

st> 1 class superclass
Integer
st> 1 class superclass methodDictionary size
54

st> 1 class superclass superclass
Number
st> 1 class superclass superclass methodDictionary size
100

st> 1 class superclass superclass superclass
Magnitude
st> 1 class superclass superclass superclass methodDictionary size
8

st> 1 class superclass superclass superclass superclass
Object
st> 1 class superclass superclass superclass superclass methodDictionary size
127

st> 1 class superclass superclass superclass superclass superclass
nil
st> 1 class superclass superclass superclass superclass superclass 
methodDictionary size
0

> 
> Am I "on track" at all, so far?

I don't know ... in case of doubt ask your system what it thinks of it.
Smalltalk's powers of reflection are amazing.

> So, when a person begins to design an OOP/GST program/script, with
> what Class do you start? 

Specifically GNU Smalltalk allows you to not use any class.
You can do like you would in Ruby and hack up a quick script,
wrap it in Eval[ ... ] and be done with it.

You _might_ discover, however, that your code could be sooo
much nicer, if you wrapped that part here into an object, as
you'd get rid of passing along that same parameter again and
again. Or you'll find that you're sending a whole bunch of
messages to the same receiver, which just begs to become
a new method in the receiver's class.

> Let say that I want to create a console app -
> say a text-based calculator (which eventually I'll migrate to
> ncurses). The app will (pseudo-code) do the following:

OTOH, you could start with some class Calculator, that could
work, too :-)

> 
> print-to-screen "Duke's Kick-ass GNU-Smalltalk Calculator"
> skip a line
> print-to-screen "Select a math Operation [+ - * /]:
> wait for user input, then inhale it
> print-to-screen "Enter first operand":
> 
> You get the idea!
> 

Object subclass: Calculator [
  start [
    Transcript nextPutAll: 'Duke''s ...'; cr; cr.
  ]
  repl [ |line|
    [ "line := read a line"
      "are we at EOF"
    ] whileFalse: [
       Transcript nextPutAll: (self eval: line)
    ]
  ]
  eval: anExpression [ "left as an exercise" ]
]

> What Class do I use to start the Inheritance ball rolling? String?
> Math? Is there a "template" type of thing to organize the OOP design?

Don't get too hung up on inheritance, it is a one-shot weapon
in Smalltalk, it is not called Single Inheritance for nothing.
You might be better off to compose your application objects of
"builtin" objects, as you can then choose which parts of their
behavior to expose and what to hide.

> 
> In C - which I know very little of - you have the general structure:
> 
> prototypes go here
> global vars go here
> 
> blah main()
> {
> local vars go here
> Opening statement goes here
> etc
> etc
> }
> 
> other functions go here
> 
> I probably don't have the C program structure dead on, but you get the
> point I hope. So far, my impression of OOP/Smalltalk classes is that
> they're like Perl's CPAN modules repository - is that correct?
> 
> I'm using the a couple of GST tutorials to get me started with the
> syntax etc, but I'm still not clear on how to start "thinking in OOP"
> - obviously.

Try to get hold of "Smalltalk, Objects and Design" by Chamond Liu.
If you want to dive in real deep and are not afraid of the occasional
(good) headache, try Andres Valloud's "A Mentoring Course on Smalltalk".

Most of all: Find out ways to discover the answers to your questions
in your own image.

s.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]