arguments and assignment
Jecel Assumpcao Jr
jecel at merlintec.com
Tue May 1 01:21:44 UTC 2001
Here is a strange idea: what if instead of allowing arbitrary names for
arguments, we forced them to always match the part of the keyword
selector that they are associated with?
For example, 'x:' would have 'x' as an argument and
'baseDrawOnCanvas:Center:Radius:Color:' would have 'canvas', 'center',
'radius' and 'color' as its four arguments. Note that I eliminated
'baseDrawOn' from the first argument name and just grabbed the letters
starting with the last capital one.
Bad points: some keywords would have to be renamed so we wouldn't have
arguments named 'on' and so forth. In particular,
'perform:With:With:With:' would no longer be acceptable. This would
complicate the set of 'value:With:With:' messages for blocks. It would
also be easier to end up with an argument with the same name as an
object's slot, though that shouldn't be hard to spot.
Good points: arguments called 'x1', 'x2'.... wouldn't be as common. But
the really interesting consequence is if we allow a method to be
missing some argument slots:
x: = ( | | self )
This is broken, right? Unless we define that the actual value of the
argument is assigned to the 'x' slot of this method's parent as found
in the ':self*' slot. That is - we are assigning to a slot in the
receiver without having to use the assigment primitive. In fact, we
could do more than a simple assignment:
color <- paint named: 'black'.
color: ( | | changed. self )
This seems like a nicer story for both assignment and argument
association (at least I would rather explain that to people than to
talk about lambda). Of course, this is missing the names for binary
selectors. Anything else?
More information about the Self-interest