Newbie, failure to understand

The section below is snipped from Ian Bartholomew's web site. It is
a great site, and I've been spending a couple of hours there working
on some of his tutorials, thanks to Ian for showing me how to create
new views in Dolphin.

Now to my problem: I don't understand how the two code snippets below
differ. As far as I can see, both answers the result of sending
#defaultCurrentState to self, when currentState is not nil. To the
client it looks the same, internally it differs in that the last
version might send the #defaultCurrentState message more times during
a programs execution than the first.

As far as I can see, both versions will answer the result of
defaultCurrentState if you set currentState to nil, while the text
seems to suggest that only the last version will do so. If someone
enlightens me as to what I am missing here, I would appreciate it.

To Ian Bartholomew, if he's reading this posting: I thought of sending
mail to you personally, but decided not to inconvenience you as the
question can probably be answered by others on the newsgroup.

<Copyright Ian Bartholomew>
Lazy initialization

It's quite common to see a variable accessor method in Smalltalk that
is lazily initialized, something of the form.

currentState
        currentState ifNil: [currentState := self defaultCurrentState].
        ^currentState

There are pros and cons for this technique (which I won't go into
here) but one problem that I find with the above is the question of
resetting to the default state. This usually means that the user of
the class either needs to know the correct default value and restore
it via the set accessor or be given public access to the
#defaultCurrentState method which may violate encapsulation.

An easy way around this is -

currentState
        currentState ifNil: [^self defaultCurrentState].
        ^currentState
</Copyright Ian Bartholomew>

Now the simple act of sending nil to the set accessor will restore the
variable to it's default. However, one situation where this would not
be applicable is where the #defaultCurrentState method is an
expensive, in terms of processor time, operation. In that case the
caching effect of the first version outweighs the value of easier
resetting.


--

Vennlig hilsen

Syver Enstad

Syver,

> As far as I can see, both versions will answer the result of
> defaultCurrentState if you set currentState to nil, while the text
> seems to suggest that only the last version will do so. If someone
> enlightens me as to what I am missing here, I would appreciate it.

You're not missing anything. The paragraph made sense to me when I wrote it
(I assume) but doesn't now. The effect of both the code snippets is the same
and I really can't see now what made me think it worth adding to the page.
Sorry <FX: shuffling of feet>

I really must do something about those web pages. There is too much on there
that is either sloppy or out of date (originally written for Dolphin 1 or 2)
and probably hinders more than it helps. Deletion seems like a good option!
There are a number of sources (Louis' web site and Ted's book to name but
two) that are more up to date and writ better.

Ian

"Ian Bartholomew" <[hidden email]> writes:

> You're not missing anything. The paragraph made sense to me when I
> wrote it (I assume) but doesn't now. The effect of both the code
> snippets is the same and I really can't see now what made me think
> it worth adding to the page.
>
> Sorry <FX: shuffling of feet>

That's completely ok, in fact I am glad that I was not mistaken,
because that would mean that I hadn't understood the basics of the
language.


> I really must do something about those web pages. There is too much
> on there that is either sloppy or out of date (originally written
> for Dolphin 1 or 2) and probably hinders more than it
> helps.

No, the pages are great. While it is true that some of them seems to
be written for an earlier version of Dolphin, that is just a fact of
life.

> Deletion seems like a good option!

On the contrary, I think they are very good, please don't delete
them. Your tutorials are nicely written and concise and to the
point. I've been through, the build shell and build view tutorials +
the tips page. While we agree on the lazy initialization thingy, I
think that "the workspace is your friend" is very much to the point. I
for one need more pages like yours not less!

>
> There are a number of sources (Louis' web site and Ted's book to
> name but two) that are more up to date and writ better.

I am using Ted's book actively, but it's very nice to have other input
too. I think it's good to have input from several sources. The focus
will always be different.

--

Vennlig hilsen

Syver Enstad

I was going to leave this alone hoping someone else would do it. The effect of
those code snippets is NOT the same. Ian, you may have thought you were wrong
but you were mistaken :)

They are very different behaviors. Eg, suppose a collection were being
returned and the caller (eg another self method) wanted to add an element.
Then the 2nd version would be a bug.

Suppose you were serializing the object and the serializer bypassed accessors
and read the variables directly. Then you might like the 2nd version which
might cause the serializer not to save currentState when it was nil.

A lot of other scenarios where this difference counts could probably be found.

One thing I'm not clear on is Ian's commentary. I dont see why the client of
this object has to know anything about what the default value is. Only the
receiver has to know that. I dont see any violation of encapsulation (other
than to the extent that all public accessors are VOE, with which view I do not
agree).


On Mon, 18 Mar 2002 01:40:16 GMT, Syver Enstad <[hidden email]>
wrote:

> I was going to leave this alone hoping someone else would do it. The
> effect of those code snippets is NOT the same. Ian, you may have
> thought you were wrong but you were mistaken :)

Let's call it half-wrong then ;). I agree with you you that there are issues
when the default object is mutable and also performance repercussions (which
the original web page did cover) but the way the text reads, implying that
the effect of the second version is different to the first, is wrong.  In
both cases using the setter to set the value to nil will result in the
default value being answered by the getter - which is what Syver was asking
about.

As you say, the way it is implemented can have a bearing on subsequent
behaviour - but that is another story

Regards
    Ian

Syver,

> I am using Ted's book actively, but it's very nice to have other input
> too. I think it's good to have input from several sources. The focus
> will always be different.

If you aren't "all booked out", I would highly recommend Smalltalk Best
Practice Patterns by Kent Beck for discussions about the sorts of issues
you're considering.

http://www.object-arts.com/wiki/html/Dolphin/SmalltalkBestPracticePatterns.h
tm

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

"Andy Bower" <[hidden email]> writes:
>
> If you aren't "all booked out", I would highly recommend Smalltalk
> Best Practice Patterns by Kent Beck for discussions about the sorts of
> issues you're considering.

Got it already, and the Design Patterns companion too. They are both
very good.

<off topic>
I even got a Smalltalk job offer near the place I live the
other day because I posted on comp.lang.smalltalk. So I have a fair
hope of being able to sustain my self and my family by programming
Smalltalk, which would be really great. So who says that posting to usenet is
a waste of time ;-)

--

Vennlig hilsen

Syver Enstad