[self-interest] arguments and assignment

[Toby Everett]

> Perl has a hidden variable that lets you access 
> the args for that activation. 
> 
> Neat, but can be dangerous in the wrong hands..
Perl also supports prototypes, which allows the subroutine to "define" what
sorts of things it expects, so as to allow the parser to make things behave
more like the builtins.

For instance, the built-in "grep" can take a subroutine as an argument, as in:

@foo = grep {$_ > 20} @bar;

Which assigns into the array @foo all those elements of @bar which are greater
than 20 (the $_ is a "default" variable).

If I wrote my own grep, mygrep, without prototypes, it would have to be
called like this:

@foo = mygrep sub {$_ > 20}, @bar;

The sub {} indicates that it's a subroutine (otherwise it would normally be an
anonymous hash constructor:).

But if you write the proper prototype for the mygrep subroutine, it too can
behave just like the built-in grep.


Getting back to the original issue, though, it strikes me as ugly that Self
has to have multiple definitions for perform.  They're all the same thing, and
it just _feels_ ugly to have multiple definitions.  Like there's something
wrong with the language.

As an analog, I'm guessing that no-one has much Visio experience, but Visio is
an incredibly cool drawing program.  Not the Visio 90% of people use, but the
Visio just under the skin.  Every shape in Visio is the result of a
"ShapeSheet" - a sort of spreadsheet.  Every vertex on the shape is, by
default, assigned to Width*x and Height*y, where x and y lie between 0 and 1,
and the coordinates are in a shifted reference frame that is relative to the
shapes location and rotation.  But that's all changeable - just go into the
ShapeSheet and change the formula.  The result is a "programable" shape.  It's
an _incredibly_ powerful concept that lets people create intelligent shapes
very easily.  The achilles heel, however, is that it has no "looping"
construct.  So developers of shapes that by their nature have "n" elements
frequently pick some specific number of maximum elements and hand-code the
rest.  Say I wanted to implement a polygon shape - it would have a
user-defined property that specified the number of sides, and it would
generate a regular polygon.  I would pick, say, 20 as the maximum number of
sides.  The resultant shape would have 20 vertexes, but when n was less than
20, I would simply stack all the unused vertexes over one vertex.  Ugly, ugly,
ugly, ugly.  Looping should have been built into the ShapeSheet structure from
the beginning (and I've even come up with a proposal for how it would be done
- it would not be that difficult).  But they didn't, and everytime I'm faced
with that sort of situation I cringe and copy and paste.

OK, that was probably way off track.  But it is very similar to the perform
situation.

--Toby Everett