This payer/payee example is exactly what I was thinking about, and I���ve tended to do as Dennis suggests and use a type suffix on the name - and wondered if that was what most people do.

I���ll certainly check what Andreas says on the topic.

Tim 

Sent from my iPhone

On 12 Jul 2018, at 06:31, Dennis Schetinin <chaetal@gmail.com> wrote:

It depends on the current level of abstraction. If you are operating at a much higher level, say transfering 
money between two accounts, you would do:
 
#transferMoney from: aPayer to: aPayee

where both aPayer and aPayee could be anAccountHolder

Why not 

#transferMoney from: payerAccountHolder to: payeeAccountHolder

?

And how does the naming depend on level of abstraction?

Practically, when a (potential) user of the method is going to invoke it, one of the first questions will be 'what kind of object I can/should pass there?'. With the classic Smalltalk convention it is quite obvious (though, the convention is not perfect itself and sometimes/often is not enough). With the  aPayer and aPayee the user will have to read the method code to learn that. 


--

Best regards,


Dennis Schetinin



����, 12 ������. 2018 ��. �� 6:29, K K Subbu <kksubbu.ml@gmail.com>:
On Thursday 12 July 2018 03:54 AM, Tim Mackinnon wrote:
> I was taught {���a���/���an���}DataType, so it would be:
>
> #name: aString

It depends on the current level of abstraction. At the lowest levels, it
is okay to use basic types like aString since classes (types) define
behavior. If you are operating at a much higher level, say transfering
money between two accounts, you would do:

#transferMoney from: aPayer to: aPayee

where both aPayer and aPayee could be anAccountHolder

Essentially, the idea to keep the message part as close to normal
statements as possible.

The book "A Mentoring Course Smalltalk" by Andres Valloud covers this
aspect in great detail.

Regards .. Subbu