[GOODIE] Arithmetic assignments (+= and friends)
Andreas Raab
Andreas.Raab at gmx.de
Wed Jun 19 11:23:10 UTC 2002
Richard,
Just two little notes on your message: a) I never claimed to solve
*your* problems as you seem to be implying. I solved a problem that I
have (and no amount of theoretical discussion will change this). b) Yes,
I know this is Smalltalk but I don't give the least bit. If I want to do
an experiment I'll do it ;-) It's your right to hate it or love it, but
*please* don't start telling me that I must not do any experiments just
because "This is Smalltalk".
Cheers,
- Andreas
> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On
> Behalf Of Richard A. O'Keefe
> Sent: Wednesday, June 19, 2002 5:08 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: [GOODIE] Arithmetic assignments (+= and friends)
>
>
> I now understand the += proposal.
> Let me see if I can respond to some of my own points.
>
> (1) += HAS to be a binary selector rather than a compound from a
> binary selector and an assignment symbol because it IS a
> binary selector.
>
> (2) There is a marked syntactic difference from other binary
> selectors, however. The thing on its left must be a
> simple variable.
>
> (3) The effect of var $= exp, for some selection of $ binary
> selectors,
> is
> var := var perform: #$= with: exp
> although presumably it would be implemented using a direct message
> send rather than really using #perform:with:
>
> (4) The complaints by several people that writing x := x + y
> just isn't
> a big deal miss the point. The point is to have notational
> uniformity between updating an object (which is the value of x)
> that can increment itself and updating a variable (whose value
> is immutable and cannot increment itself).
>
> (5) There could very well be an automatic relationship
> between $= and $.
> Add to object a bunch of methods like
> $= anObject
> "Implement the $= for immutable receivers.
> Mutable receivers should override this with
> something better."
> ^self $ anObject
> (Here as elsewhere, replace $ by +, -, *, /, and so on.)
>
> This proposal doesn't solve any problem that I have.
> However, it does create some problems.
>
> (a) If I *should* happen to create a -= method for some class
> (such as Polynomial, maybe) it will no longer be legal for me
> to write (srs at: 1) -= monomial.
>
> It will need an exceptionally well worded error message to explain
> why what seems like (and according to all current
> textbooks, IS) an
> ordinary binary selector "misbehaves".
>
> (b) If I *think* x and y hold oops to mutable things like Points,
> but I'm wrong, then x += y will not only appear to succeed,
> it will change the value of x, which may come as a nasty surprise.
>
> (c) There are a whole bunch of update assignments one would
> like to have
> such as raisedTo:=, min:=, max:=, for which the efficiency and
> uniformity arguments are equally compelling, but which *cannot* be
> handled this way. For somewhat different reasons, while
> vectorwise
> logical operations make sense, |= is unavailable.
>
> If this were Perl, I'd say "fine, go ahead, one more wart on the
> gargoyle." This is Smalltalk. I think the idea creates more problems
> and inconsistencies than it removes. The e-correspondence so far has
> shown that it's quite good at confusing people.
>
> Nothing actually stops anyone writing
> x := x += y
> right now, and nothing (Smalltalk, got to love it) stops anyone
> adding += and friends to Number. So most of the apparent benefits
> can be obtained with no compiler changes.
>
> Now can I have {v1. v2. v3} := expr back? (:-) (:-)
>
>
More information about the Squeak-dev
mailing list
|