Dominic Fox <dominic.fox1 at ntlworld.com> wrote:
	* If I want to expose an instance's private fields, do I have to code accessor 
	methods every time? Is there an alternative to writing
	
	getFoo
		^ foo
	
	and 
	
	setFoo: newFoo
		foo := newFoo
	
	over and over again?
	
First, *DON'T* call the methods #getFoo and #setFoo:.
Common Smalltalk practice is to name the accessor method
#foo and the mutator method #foo:, e.g.

	foo
	    ^foo
	foo: newFoo
	    foo := newFoo.

See for example Kent Beck's "Smalltalk Best Practice Patterns"
or whatever the title is.  Actually, see _anything_ by Kent Beck.

Second, remember that there is often plenty to do after allowing
an instance variable to be changed.  For example,
    TextKern>>
    kern: kernValue
        kern := kernValue.
        self reset.
For something which is going to be a model in a GUI, you may need to
use some kind of #changed message.  With single-key mutator creation,
it would be too easy to forget this.  Actually, there aren't many cases
where it is appropriate to omit checks; Java programmers often seem to
think that just because an actual parameter has the right type it isn't
nil and forget to check for that.

Third, remember that the Smalltalk IDE is fully programmable.

For example, suppose the variable 'myClass' holds a reference to
your class.   Then

    myClass compile: 'foo\    ^foo' withCRs.
    myClass compile: 'foo: newFoo\    foo := newFoo.' withCRs.

will add these methods.  They'll go in the 'as yet unclassified'
method category; I leave it to your explorations to figure out how
to put them in the 'accessing' category, although leaving them in
the unclassified category may be a good way to show that they need
real thought still.

	* Is the best way to make what in C++ or Java you'd call
	"constructors" to write class methods that create, initialize
	and then return an instance, e.g.
	
That's what a constructor does.

	newFooWithBar: initialBar
		| newFoo |
		newFoo := Foo new; setBar: initialBar.
		^ newFoo
	
	or is there a more concise way?
	
You normally use "self" rather than the class name.  So this
would normally read

	newWithBar: initialBar
	    ^self new bar: initialBar; yourself

	* Can I treat blocks as first-class entities, e.g. return them
	from methods, pass them around etc?

Pass them around, certainly.  A longstanding defect in Squeak has been
that it has not correctly implemented closure semantics for blocks.
Anthony has done a lot of work on that, and I *hope* some version of
his code will finally be implemented in 3.6.

	Can I use them to implement LISP-like closures?

They *are* Lisp-like closures.

	Even if I can, is this a "natural" smalltalky way to do things?

Hint:  Smalltalk *has* blocks.  They're there to use in any way that
helps.  (I note that current versions of Eiffel has "agents", the same
thing by a different name.)

	* What about function/method pointers?

There aren't any.

	Can I treat one of an instance's methods as a block,

No, because they have different interfaces.  A block is effectively
a _bound_ method.

	or do I have to make a new block and call the method inside that?

Yes, but blocks are syntactically lightweight; it's no big deal.
Once you get used to blocks you seldom _want_ to pass a function pointer
anyway; blocks are so much more powerful and convenient.

	Finally,
	
	* Is this list a good place to ask questions like this? If it isn't, is there 
	a more suitable one?
	
There is also comp.lang.smalltalk, but this is a great place to ask
questions like this.