Eliminating assignments and variable syntax (accessors)
Jarvis, Robert P.
Jarvisb at timken.com
Tue Aug 3 12:15:29 UTC 1999
Re: keep the receiver in message patterns - YES, PLEASE!!!!!
Re: getting rid of assignments: In your example "var" is not part of self.
How about using something like "thisContext" instead, which would be more
descriptive of the owner of "var"?
<ramble>
To this point I haven't seen a proposal for eliminating assignments which
made me want to leap to my feet and shout "Amen!". I feel a bit like a
moth, drawn to the flame of functional programming, but I dislike the
functional community's obsession with static type checking. The elimination
of state from programming seems to confer some real advantages - but without
state what is an object?
</ramble>
Bob Jarvis
The Timken Company
> -----Original Message-----
> From: Stephen Pope [SMTP:stp at create.ucsb.edu]
> Sent: Monday, August 02, 1999 5:09 PM
> To: squeak at cs.uiuc.edu
> Subject: Re: Eliminating assignments and variable syntax (accessors)
>
> This is getting a bit involved, but I have another idea. First, two
> principles:
>
> 1) We should keep the receiver in message patterns. (I'm against
> abbreviated message-sends.)
>
> 2) We want to get rid of assignment. (It's always a hack, except if you
> make it a function as in LISP, or do away with it, as in functional
> languages.)
>
> Solution: If we had the notion of "implicit accessors," we could write,
>
> | var |
> self var: 42.
> Transcript show: self var printString; cr.
>
> The code that implements doesNotUnderstand (or, even better, handles the
> exception MessageNotUnderstood) could then look in the local scope to
> see if there's a variable named "var" and handle the assignment and
> reference as "implicit accessing" -- this way it appears that we have
> accessors even for local temp. vars.
>
> (This is very similar to several other schemes that use
> doesNotUnderstand for "generic behavior" or property list objects.)
>
> If we did it this way, we could do away with all accessors (except for
> the speed hit we'd take passing though doesNotUnderstand on IV
> accesses).
>
> stp
>
> --
>
> Stephen Travis Pope -- http://www.create.ucsb.edu/~stp
> stp at create.ucsb.edu -- stp9 at cornell.edu
More information about the Squeak-dev
mailing list
|