Help with a Tutorial in the Dolphin Education Centre

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Help with a Tutorial in the Dolphin Education Centre

Tony Bailey
Hi,

I am very new to Smalltalk and am just about to undertake an Open
University course which uses Smalltalk.

In order to try and get ahead I have begun to play around with the
Dolphin Smalltalk program and have been following the Beginners Guide
and Tutorials.

Today I have hit a hurdle and require some assitance with the Tutorial
titled ' A Scribble Pad Component'.

The area of concern is near to the end of the lesson and is sub titled
Accessing Ink. What exactly does 'You can access the ink data using
#model and save it away later.' mean? It is then followed by  inkData
:= Scribble model. (which I presume  I have to evaluate in the
currently open workspace).

I would like to try and get over this hurdle continue using the
tutorials in oder to get a better understanding of Smalltalk ready for
my course commencement.

I thank you in advance for any help that you can offer to me.

regards
Tony


Reply | Threaded
Open this post in threaded view
|

Re: Help with a Tutorial in the Dolphin Education Centre

Schwab,Wilhelm K
Tony,

> The area of concern is near to the end of the lesson and is sub titled
> Accessing Ink. What exactly does 'You can access the ink data using
> #model and save it away later.' mean?

"save it away for later" is probably Andy's way of saying (while in one
of his more Shakespearean moods), well, just that :)  Note that the
tutorial subsequently uses the resulting object (an instance of
ListModel) as the model for another presenter.

When you begin building composite presenters, you will frequently use
instance variables to point to specific sub-presenters.  It arises in
many other cirumstances too.  Whether holding something is a performance
optimization, a convenience, or a necessity depends on the cirumstances.

Note that if nothing holds a reference to a given object, the garbage
collector will remove it from the image.  Of course, if nothing holds a
reference to a given object, then you have effectively "forgotten where
it is".


 > It is then followed by  inkData
> := Scribble model. (which I presume  I have to evaluate in the
> currently open workspace).

I think that should be

   inkData := scribble model.

to refer to scribble the workspace variable as opposed to Scribble the
class.

Was this "full of sound and fury, signifying nothing", or did it
actually help you?

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Help with a Tutorial in the Dolphin Education Centre

Ian Bartholomew-19
In reply to this post by Tony Bailey
Tony,

> I am very new to Smalltalk and am just about to undertake an Open
> University course which uses Smalltalk.

Welcome

> The area of concern is near to the end of the lesson and is sub titled
> Accessing Ink. What exactly does 'You can access the ink data using
> #model and save it away later.' mean? It is then followed by  inkData
> := Scribble model. (which I presume  I have to evaluate in the
> currently open workspace).

It's a typo.  It should read

inkData := scribble model

It is showing that you can extract the inkData (a collection of instances of
InkStroke stored in the Scribble instance's #model instance variable) from
the instance of Scribble that was used to do the drawing so that it can
later be used to redraw the same sequence of lines in a new Scribble
instance.

And yes, you will have to evaluate that line in the same workspace in which
you created the Scribble instance.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.


Reply | Threaded
Open this post in threaded view
|

Re: Help with a Tutorial in the Dolphin Education Centre

Tony Bailey
In reply to this post by Schwab,Wilhelm K
Bill Schwab <[hidden email]> wrote in message news:<clmd0l$gp2$[hidden email]>...

> Tony,
>
> > The area of concern is near to the end of the lesson and is sub titled
> > Accessing Ink. What exactly does 'You can access the ink data using
> > #model and save it away later.' mean?
>
> "save it away for later" is probably Andy's way of saying (while in one
> of his more Shakespearean moods), well, just that :)  Note that the
> tutorial subsequently uses the resulting object (an instance of
> ListModel) as the model for another presenter.
>
> When you begin building composite presenters, you will frequently use
> instance variables to point to specific sub-presenters.  It arises in
> many other cirumstances too.  Whether holding something is a performance
> optimization, a convenience, or a necessity depends on the cirumstances.
>
> Note that if nothing holds a reference to a given object, the garbage
> collector will remove it from the image.  Of course, if nothing holds a
> reference to a given object, then you have effectively "forgotten where
> it is".
>
>
>  > It is then followed by  inkData
> > := Scribble model. (which I presume  I have to evaluate in the
> > currently open workspace).
>
> I think that should be
>
>    inkData := scribble model.
>
> to refer to scribble the workspace variable as opposed to Scribble the
> class.
>
> Was this "full of sound and fury, signifying nothing", or did it
> actually help you?
>
> Have a good one,
>
> Bill



Bill,

Firstly, a thank you to yourself and Ian for the courtesy of a reply.

To be honest I am a little lost with it all at the moment as I have no
previous knowledge of any object oriented language. The basics are
gradually sinking in eg. unary, binary and keyword messages and the
fact that classes govern the behaviour of objects, where as methods
are the code that determines how the messeges should be executed.

I am trying to progress on to more details regarding classes, class
hierarchy, superclass and subclass. I have a short period of time
before my course actually commences, ie Feb 2005, but I would like to
have adecent grasp on the fundamentals prior to beginning.

The course itself uses a specific type of Smalltalk called LearnWorks.
This is proving difficult to get hold of, hence my decision to play
around with Dolphin.

Also, it has helped just finding this user group.

Tell me it does get easier!

kind regards
Tony


Reply | Threaded
Open this post in threaded view
|

Re: Help with a Tutorial in the Dolphin Education Centre

Udo Schneider
Tony Bailey wrote:
> I am trying to progress on to more details regarding classes, class
> hierarchy, superclass and subclass. I have a short period of time
> before my course actually commences, ie Feb 2005, but I would like to
> have adecent grasp on the fundamentals prior to beginning.
To get a feeling for objects without being "disturbed" by syntax I would
recommend a paper called "Design Principles Behind Smalltalk" by Dan
Ingalls. You can find an online version here:
http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html


If you want to go on with the basic class library the following paper is
quite good:
http://www.inf.ufsc.br/poo/smalltalk/ibm/

Finally there is a great site with Smalltalk Books which are either out
of print and in the public domain now or where the publisher gave
permission to put it online:
http://www.iam.unibe.ch/~ducasse/FreeBooks.html


> Tell me it does get easier!
It does! ;-)

CU,

Udo


Reply | Threaded
Open this post in threaded view
|

Re: Help with a Tutorial in the Dolphin Education Centre

Stefan Schmiedl
In reply to this post by Tony Bailey
On 28 Oct 2004 13:00:55 -0700,
Tony Bailey <[hidden email]> wrote:
>
> To be honest I am a little lost with it all at the moment as I have no
> previous knowledge of any object oriented language. The basics are
> gradually sinking in eg. unary, binary and keyword messages and the
> fact that classes govern the behaviour of objects, where as methods
> are the code that determines how the messeges should be executed.

This sounds like a very good summary. Remember it, when you get lost.

> Tell me it does get easier!

It will get easier. Currently you're learning several things
simultaneously:
- the Smalltalk language
- the Smalltalk environment, Dolphin variant
- the Smalltalk Way of Thinking

If you persist, you will gain great insights into how things ought
to work in OO-land. You'll fall for dynamic typing, and have several
steamy affairs with the integrated debugger.

Loads of fun are waiting for you.

s.


Reply | Threaded
Open this post in threaded view
|

Re: Help with a Tutorial in the Dolphin Education Centre

Schwab,Wilhelm K
In reply to this post by Tony Bailey
Tony,

> To be honest I am a little lost with it all at the moment as I have no
> previous knowledge of any object oriented language.

You have picked an excellent language in which to start.  You have also
picked an excellent implementation of it.


 > The basics are
> gradually sinking in eg. unary, binary and keyword messages and the
> fact that classes govern the behaviour of objects, where as methods
> are the code that determines how the messeges should be executed.

Probably the best explanation of Smalltalk syntax is in the August 1981
issue of Byte Magazine.  My "copy" (literally) is at home, so I don't
have easy access to it.  If you can find the magazine, look for an
article with colored boxes around keywords.  I was already very
comfortable with Smalltalk syntax (so I might not be the best judge),
but it struck me as a great way to illustrate it for newbies.

Have a look at

    http://www.object-arts.co.uk/wiki/html/Dolphin/AdviceToBeginners.htm

as well as other Smalltalk and Dolphin tutorials. Ted Bracht wrote a
book about Dolphin that might interest you; my understanding is that it
is out of print, but still available on Amazon and elsewhere.

Do you have a CD burner?  Indulge yourself here:

   http://www.iam.unibe.ch/~ducasse/FreeBooks.html


> I am trying to progress on to more details regarding classes, class
> hierarchy, superclass and subclass. I have a short period of time
> before my course actually commences, ie Feb 2005, but I would like to
> have adecent grasp on the fundamentals prior to beginning.

If you search around in Ian's archives, you might find reference to "The
Strap".  Classes are objects, and objects are instances of classes.  If
you think about that for a while, it will drive you nuts.  However, the
CHB sorts it out nicely for you, by presenting  class and instance tabs.

For a good long while, you can fairly safely think of creating class
methods that correspond to message you would send to a class itself, such as

    Array new:10.

Instance methods correspond to messages you would send to an instance of
a class.

Inheritance is more the subject of book chapter than a newsgroup
posting.  Subclasses inherit the state and behavior of their super
classes, and can add state, and add override or alter behavior.  In a
method, super begins the lookup not at the receiver, but at its
subclass.  It might look something like this:

initialize
    super initialize.
    data := OrderedCollection new.

When executed, the above code "does whatever the super class does" and
then assigns a new ordered collection to the variable data.

This is very powerful stuff, and you will eventually learn how to use it
to your advantage.  Note that beginners in fact tend to over use
inheritance.  You will see discussions on topics such as "is a vs. uses
a", etc.  Very often, the correct approach is to contain an object of a
particular class rather than to extend it by inheritance.  The only way
to make sense of that is to gain some experience.  You will make some
mistakes along the way, but that's not a big deal.


Read the next paragraph later :)

IMHO, the first class/instance danger you are likely to hit is with
#initialize.  It is very common to super-send it (see below) in instance
methods, but you generally should **not** super-send on the class side.
On the class side, super initialize can do ugly things, but it should be
a while before you find the need to mess with that.



> The course itself uses a specific type of Smalltalk called LearnWorks.
> This is proving difficult to get hold of, hence my decision to play
> around with Dolphin.

I think you will find it is called LearningWorks, though that might not
make it an easier to locate.


> Tell me it does get easier!

It does, eventually :)  Actually, one of Mark Guzdial's books references
a small group of students with no Smalltalk experience, who managed to
turn out a substantial extension of a web server in a matter of weeks.
Hang in there.  Ask lots of questions here.  This group is populated
with folks who can mentor you.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Help with a Tutorial in the Dolphin Education Centre

Peter Kenny-2
"Bill Schwab" <[hidden email]> wrote in message
news:clrpf3$1464$[hidden email]...

>  In a
> method, super begins the lookup not at the receiver, but at its
> subclass.  It might look something like this:
>
> initialize
>     super initialize.
>     data := OrderedCollection new.
>
> When executed, the above code "does whatever the super class does" and
> then assigns a new ordered collection to the variable data.

Bill

Please, please tell me that 'subclass' in the first sentence above is a typo
for 'superclass'. Otherwise, whatever this does for Tony, it will drive me
nuts!

Peter Kenny


Reply | Threaded
Open this post in threaded view
|

Re: Help with a Tutorial in the Dolphin Education Centre

Schwab,Wilhelm K
Peter,

>> In a
>>method, super begins the lookup not at the receiver, but at its
>>subclass.  It might look something like this:
 >
> Please, please tell me that 'subclass' in the first sentence above is a typo
> for 'superclass'. Otherwise, whatever this does for Tony, it will drive me
> nuts!

Thanks for catching it.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]