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... ;) Am I "on track" at all, so far? So, when a person begins to design an OOP/GST program/script, with what Class do you start? 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: 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! 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? 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. -- duke _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
On Sun, 10 Jan 2010 09:52:42 -0700 (MST)
Duke Normandin <[hidden email]> 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. _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
On Sun, 10 Jan 2010, Stefan Schmiedl wrote:
> On Sun, 10 Jan 2010 09:52:42 -0700 (MST) > Duke Normandin <[hidden email]> wrote: > > > Or more specifically, "How does one *start* an OOP/GST program? [snip the good stuff] Great stuff! I'm going to re-read, and re-read some more. However it sure explained quite a few things for me. Thank you! > 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". Cool... > Most of all: Find out ways to discover the answers to your questions > in your own image. I hear you! Your (snipped) examples have shown me how I can send "query" messages to classes, as well as "verb" - "do_something" - messages, among others. -- duke _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
On Sun, 10 Jan 2010 13:17:10 -0700 (MST)
Duke Normandin <[hidden email]> wrote: > On Sun, 10 Jan 2010, Stefan Schmiedl wrote: > > > On Sun, 10 Jan 2010 09:52:42 -0700 (MST) > > Duke Normandin <[hidden email]> wrote: > > > > > Or more specifically, "How does one *start* an OOP/GST program? > > [snip the good stuff] > > Great stuff! I'm going to re-read, and re-read some more. However it > sure explained quite a few things for me. Thank you! thanks ... I'm going to do this a few more times, then I'll bottle it and sell it for one dollar only! Guaranteed to improve all your OO ailings! And ingrown toenails, too! s. _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
On Sun, 10 Jan 2010, Stefan Schmiedl wrote:
> On Sun, 10 Jan 2010 13:17:10 -0700 (MST) > Duke Normandin <[hidden email]> wrote: > > > On Sun, 10 Jan 2010, Stefan Schmiedl wrote: > > > > > On Sun, 10 Jan 2010 09:52:42 -0700 (MST) > > > Duke Normandin <[hidden email]> wrote: > > > > > > > Or more specifically, "How does one *start* an OOP/GST program? > > > > [snip the good stuff] > > > > Great stuff! I'm going to re-read, and re-read some more. However it > > sure explained quite a few things for me. Thank you! > > thanks ... I'm going to do this a few more times, then I'll > bottle it and sell it for one dollar only! Guaranteed to > improve all your OO ailings! And ingrown toenails, too! Fixing in-grown toenails is good! I've met my first Smalltalk snake-oil salesman ;) But is it guaranteed to reverse the "damage" that http://www.cs.loyola.edu/~binkley/792/articles/oopbad.htm could cause. I have to admit that I'm reading the page and wondering.. Ironically, I came across the article searching for Chamond Liu book. (*_*) -- duke _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by dukester
begin quoting Duke Normandin as of Sun, Jan 10, 2010 at 09:52:42AM -0700:
> Or more specifically, "How does one *start* an OOP/GST program? [snip] > So, when a person begins to design an OOP/GST program/script, with > what Class do you start? The short answer? The REPL. Not with a class, but the Read-Evaluate-Print-Loop. > 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: > > 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! Um, have you started with "Hello, World" yet? That's the traditional first program. :) [snip] -S. _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Free forum by Nabble | Edit this page |