Re: Newbie question: immutable objects in Smalltalk

[panu]

Chris Uppal wrote:

> Smalltalk /programmers/ do make a fairly strong distinction made between
> private and public, but that's a convention rather than something built into
> the language. It is communicated in various ways, and with various degrees of
> effectiveness

An alternative to this is to use a pattern which in fact is implicit
in Smalltalk already: "Make ALL methods public. Instead of defining
private methods, delegate to private components".

In other words, if you think you want some method be private,
why not instead refactor that functionality into a component!?

From another viewpoint this is very close to the Bridge -pattern:
Keep implementation and interface in separate objects. Many good
things follow. For instance, 'implementation' can now inherit
via a different path than the interface, reducing coupling. The
implementation can also be replaced at runtime, to represent
changing state.

As to immutability, the methods of the object still control
that. But, I believe in Dolphin 6, you can explicitly set an
object to be immutable too.

- Panu Viljamaa

[Chris Uppal]

panu wrote:

> An alternative to this is to use a pattern which in fact is implicit
> in Smalltalk already: "Make ALL methods public. Instead of defining
> private methods, delegate to private components".

Yes, that's a valid pattern. You can't easily use it to remove /all/ private
methods, though.

Mildly interesting technical challenge: create a class which responds to the
instance creation method
#named: aString
with an object that will respond to the message
#name
with the given String, and which has no (private or public) methods that change
its state. You can pretend that the Object methods like #atut: or
#instvarAtut: do not exist, so you don't need to bother overriding them to
#shouldNotImplement, but you still are not allowed to call them yourself.

The /cleanest/ solution I can think of is to use a subclass that /does/ have
some kind of state-mutation method (whether just a setter for a String instvar
or a more complex operation to pass an appropriately configured delegate in).
Create an instance of that subclass, configure it, and then use #becomeA: to
switch its class to the immutable superclass...

(Can't think why it didn't occur to me to suggest that to the OP ;-)

-- chris

[panu]

Chris Uppal wrote:

> Mildly interesting technical challenge: create a class which responds to the
> instance creation method
> #named: aString
> with an object that will respond to the message
> #name
> with the given String, and which has no (private or public) methods that change
> its state.

That is an intriguing problem, and your
#becomeA: is a neat trick. Yet creating
a new subclass just for this purpose is
a bit of work. And like many programmers
I'm a bit wary of #become:, for historical
reasons.

Another way then might be: Allow the
instance-method #name: to set the value,
but only once!

In other words, if the value is non-nil,
the setter will just ignore the argument.

Since the class controls the instance-creation,
it can make sure the value is set, after which
no-one else can reset it.

Thanks
-Panu Viljamaa