Tutorial Model: question

Hello
Sorry if this question is too simple, but I'm not able to
see thru the forest on my own.

In the tutorial "Personal Money", #model: method is...
=====================================
PersonalMoneyShell>>model: aPersonalMoney
        "Set the model associated with the receiver."

        super model: aPersonalMoney.
        ownerPresenter model: (aPersonalMoney aspectValue: #owner).
        accountsPresenter model: (aPersonalMoney accounts).
=====================================
But if I were writing this myself I would have probably written
 "accountsPresenter model: (aPersonalMoney aspectValue: #accounts) "
<accepted it> <execute 'PersonalMoneyShell show'> and get the debugger
saying
'ValueAspectAdaptor does not understand #do'

Okay, but how would a beginner know to set accountsPresenter model to
'aPersonalMoney accounts'
instead of trying 'aPersonalMoney aspectValue: #accounts' first, just
like the line
before it, 'ownerPresenter model: (aPersonalMoney aspectValue: #owner),
use of a ValueAspectAdaptor ?

Thanks in advance for sharing your knowledge
ACG

acg wrote:
Each type of  presenter expects to interact with a particular type of
model.  Once you know the presenter - usually the class comment will
tell you more about the model.

Eg: ListPresenter class comment: ' ListPresenter implements a
<listPresenter> component that can be used to display the contents of a
<listModel> within a <listView>'

<listPresenter> <listModel> and <listView> are protocols - use the
protocol browser to see which classes implement these protocols.  A
<listModel> unsurprisingly is implemented by the ListModel class.  The
expression 'aPersonalMoney accounts' returns the ListModel object
containing the account objects as this is how the PersonalMoney objects
are initialized.

TextPresenter comment:  'TextPresenter is a <valuePresenter> that
displays a <valueModel> onto a <readableString> value.'

So your model needs to be a <valueModel> .  Your TextPresenter only
expects to sent #value and #value: to the wrapped object.  Explaining
how value models work is tricky in a short message.  But in the
smalltalk way you should creates some objects and experiment.

'hello' asValue  - inspect.
In the evaluation pane (pale yellow background) display it on 'self
value' without the quotes '.  Try self value: 'what'  Inspect the
instance variables.

  Try 2 @ 3 aspectValue: #x and inspect it.
This creates a ValueAspectAdaptor such that when the message #value is
recieved it sends #x to the wrapped object.  Try sending self value: 5.

--
Edward Stow

Edward Stow wrote:
...> <listPresenter> <listModel> and <listView> are protocols - use the
> protocol browser to see which classes implement these protocols.
....
> --
> Thanks for the explanations Edward. What you said makes sense. The protocol browser is a tool that I don't know how to use. It shows me a bunch of info. But I don't what to do with the info. I have programmed in ST/V and VW versions of Smalltalk. Any hints other hints you have to make use of the protocol browser would help. The concept of  'protocol' is not transparent to me.
Thanks again.
ACG

acg wrote:

> > Thanks for the explanations Edward. What you said makes sense. The
> > protocol browser is a tool that I don't know how to use. It shows me a
> > bunch of info. But I don't what to do with the info. I have programmed
> > in ST/V and VW versions of Smalltalk. Any hints other hints you have to
> > make use of the protocol browser would help. The concept of  'protocol'
> > is not transparent to me.

Personally, when I see a comment like

    ListPresenter implements a <listPresenter> component that
    can be used to display the contents of a <listModel> within
    a <listView>

I mentally translate each "<XYX>" into "XYX or similar". Thus

    ListPresenter implements a ListPresenter-type component that
    can be used to display the contents of a ListModel (or similar)
    within a ListView (or similar)

and hardly ever use the Protocol Browser at all.  The protocol essentially
quantifies the "or similar" by explaining exactly what "similar" is expected to
mean in this context, but I don't normally find that I need that level of
precision -- of course, that's partly because I'm pretty familiar with the
Dolphin class hierarchy already.

The idea that a protocol is trying to express is to describe the
responsibilities that a given object can accept (or, equivalently, the
abilities that it is expected to have) in order to be used in a given context.
So, the model for a ListPresenter is expected, among other things, to be able
to remove all it's elements if it is sent #removeAll.  (BTW, this illustrates
an error in either the comment or the definition of <listModel>, since that
only includes <#list #list:> but a ListPresenter may also send #removeAll to
its model.)

The actual implementation of protocols is as a list of the messages which the
object guarantees to understand.  That falls short of the intent of protocols
in several ways (it doesn't guarantee that it will do the "right think", it
doesn't guarantee other aspects of behaviour like what events it will trigger,
and so on), but it is occasionally useful.

For instance, the protocol <installableSystemTool> explains succinctly what
messages the system will send to any object (typically a class object) which
wants to have itself installed as a system tool.  The information is by no
means comprehensive, but it is a useful start.

    -- chris

>... I mentally translate each "<XYX>" into "XYX or similar" Thus
>
>     ListPresenter implements a ListPresenter-type component that
>     can be used to display the contents of a ListModel (or similar)
>     within a ListView (or similar) ...
Hi Chris
  That helps a lot. I appreciate your taking time to explain the
what's, how's and why's of protocols and class comments.

ACG