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?

-- Jecel



More information about the Self-interest mailing list