Steve Aldred wrote:
> ..
> What Beck suggests tells you what it means. What you are trying to do is
> remove that useful knowledge and say what type it is.
This is a misconception. Naming an argument in the STTs style
doesn't prevent you from indicating its 'meaning' as well.
I have 4 arguments showing how this is possible and indeed easy:
A) You could define the familiar:
at: aKey put: aValue [1.]
in STTs as:
at: keyObject put: valueObject [2.]
Now the argument name indicates both the 'meaning' and the type.
Granted that [2.] is a bit longer than [1.], but you might
expect some price to pay for specifying *both* the type and
the meaning.
B) Secondly, some might actually prefer to write:
atKey: anObject1 putValue: anObject2 [3.]
or:
mapKey: anObject1 toValue: anObject2 [3b.]
or:
associateKey: anObject1 withValue: anObject2 [3c.]
Above 'meaning' is indicated by the keywords.
I for one believe it is better in general to use keywords
rather than argument names to reveal the 'meaning'. Why?
Because then the meaning of the operation is visible also
in places where you *call* it.
There is just one place where you define the method, but
several where you call it from. If the meaning is visible
also in the calling places, then the 'total' readability
of your code increases.
C) Thirdly, in fact [1.] and [2.] have exactly
the same interpretation in STTs!
In [1.] 'aValue' can only be interpreted as specifying
the type as Object - by the "Default Rule".
So you are free to choose which ever form you prefer
- unless you want to indicate that the value should
be a String for instance.
D) Lastly, STTs defines a mechanism for Generic Types.
This means that in a subclass of Dictionary for instance
you can specify that 'Value' refers to the type String.
In that context you could then again write the familiar
[1.], but have it now *interpreted* as constraining the
type to be String in this new context.
I hope the above 4 examples show that STTs doesn't lead
to 'meaningless' method headers, but makes it easy and
'cheap' to specify the types - if that is what you want to do.
> Also, as Keith said, type is not just a class it is a protocol (interface).
> How do you support that with your mechanism?
By creating Abstract Classes.
-Panu Viljamaa
--
http://members.fcc.net/panu/SmalltalkTypes.htm
Locked
