Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!gatech!news.sprintlink.net!noc.netcom.net!netcomsv!uu3news.netcom.com!netcomsv!uucp3.netcom.com!medicus!billf
From: billf@medicus.com (Bill Foote)
Subject: Re: A Question about Blocks
Message-ID: <1995Jun1.185657.9083@medicus.com>
Organization: Medicus Systems Corp.
References: <D9Fw8C.IGA@lut.ac.uk> <3qilug$bb7@ornews.intel.com>
Date: Thu, 1 Jun 1995 18:56:57 GMT
Lines: 63

M Ireland (M.Ireland@lut.ac.uk) wrote:
>
> Smalltalk is supposedly a pure object-oriented language and I
> agree with this, but where do blocks fit in? Blocks are Objects
> in their own right (like everything in ST) but have access to
> the variables of the Class in which they were defined. How are
> these two ideas reconciled?


I don't see any conflict.  Methods are free to give away bits of
their object's state, both in the form of messages they send, and
the results they produce.  One of the ways of encapsulating a bit
of this state is with a block.

As to why blocks may access instance variables:  This is because
of Smalltalk's lexical scoping rules.  Code may access values based
on it's lexical scope (where it appears), and not where it executes.
There's nothing particularly OO or non-OO about lexical scoping.

Blocks are also a *really* elegant way of doing a number of things.
For example, suppose you want to have a button press result in a message
appearing on your transcript.  In C/Motif, for example, you'd be *forced*
to define a callback function, so your code to do this extremely simple
thing would be splattered in at least two places.  In S/T, you can do
something like this:

    aButton when: #clicked evaluate: [ Transcript show: 'It was pressed' ].

This is a small example, but this way of doing things can be *very* powerful,
particularly when the block carries around a bit of state from the object
where it was created.

A similar thing exists in many other languages:  lambda expressions (in
Lisp and "pure" functional languages), blocks in Tcl, etc.  I'd say that
blocks are orthagonal to OO, and in no way conflict with it.


Patrick Logan said:

>(Not to get into a language fight... this is just my experience.
>You may *enjoy* simulating blocks in languages that don't have them!)

Oh, *yes*.  I absolutely *loved* malloc'ing up structs and attaching them
to the the XmNuserData attribute of my Motif widgets, and the great thing
was that all of that casting through void* and explicit memory management
made the code ever so clear!

:-)

On a more serious note, this is IMHO one of the advantages of a language
like Smallalk over, say, Eiffel or Sather.  With Eiffel you can at least
encapsulate your button-press action (to take that example) in a type-safe
way, but you do end up with the "code splattering" effect.  This isn't
an awful thing, it's just a bit annoying for simple actions.  I don't see
any reason why a bit of syntactic sugar couldn't take care of this in
a "static" language like Eiffel, but so far I haven't seen it done.


--
Bill Foote                | Adde parvum parvo magnus acervus ecrit.
billf@medicus.com         | [Add little to little and there will be a big pile]
Medicus Systems           |    -- Ovid, via Frederick P. Brooks, Jr.
Alameda, CA USA           |
