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