[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