I would like to join those who oppose this valiant proposal. The main
problem for me is that it complicates the beautifully simple and uniform
syntax of Smalltalk: As an example, a: b does not have a receiver. I
consider the simple syntax one of the great things about Smalltalk
both for learning and for code readability.
If anything were to be done with variables, I would suggest making
them first-class objects. As they are, they are different from
everything else and break the uniformity of the language.
Assignments could then be handled for example as
var assign: x
thus removing the need for the assignment statement while
maintaining the syntax. A lot of other things could also be done more
easily such as (pseudocode)
(Array with: selectedVariables) do: [:var| var assign: Strinbg new]
a := ''.
b := ''.
c := ''.
> Thanks for taking the time in looking over my (admittedly pretty
> rough) idea.
> > From: "Jarvis, Robert P." <Jarvisb(a)timken.com>
> > I don't like the idea of implicit targets. One of the great
> beauties of
> > Smalltalk is its simple and very regular grammar. In my opinion adding
> > implicit targets would make the grammar more complex and less regular
> > without a corresponding gain in clarity or expressiveness.
> Yes, I also don't want to mess the syntax up. However, for
> 'reading' accesses, there is no (visible) change in syntax, it's just
> that what used to be variable references are now interpreted as message
> sends. That seems like a simplification to me.
> The only 'addition' is that for assigning values, instead of writing:
> a := b.
> you would write
> a: b.
> Considering that the colon syntax is also already in use, and that
> := gets removed, that also seems to be a simplification of the
> visible syntax, overall (a slight complication and a medium
> simplification). As a matter of fact, the compiler could treat a:= as
> equivalent to a: I have to admit that I haven't considered what this
> will do to the compiler, though.
> > I just don't see
> > a great advantage here. It seems more like a hint to the compiler
> than an
> > aid to the human.
> Well, the aid is that there is now only message sends, assignments
> have been eliminated from the language or at least hidden from view. The
> practical benefit I have in mind is that the decision wether access to an
> instance variables is direct or via accessors is made in one place
> instead of everywhere the variable is accessed. Currently, if I have
> direct instance variable access, I write.
> myInstanceVar doSomething.
> If I have accessors, I write
> self myInstanceVar doSomething.
> *everywhere* I use myInstanceVar. The same goes for write-access:
> myInstanceVar := newValue
> self myInstanceVar:newValue.
> The problem is that changes to the access policy are very expensive
> because every method *accessing* the instance-var/accessor has to be
> changed. Therefore, your (absolutely correct, IMHO) proposition that all
> instance var access be done with accessors first and directly only when
> absolutely necessary means that a lot of code has to potentially be
> modified in the latter case. With lots of coders being prone to
> premature optimiziation, they will opt for direct access instead,
> especially since it is also less typing.
> With my proposal, code can always be written as if it is using
> accessors, making it non-brittle, but at the same time it enjoys all the
> benefits cited for direct variable access (privacy, speed, less typing,
> etc.) So, I just write
> myInstanceVar doSomething.
> and this very same code will use accessors if available or direct
> access if not.
> > Also, if := is eliminated how is a reference assigned to
> > a temporary variable?
> Trickery. Just like with instance variables, the compiler detects
> that there is a local variable of that name and emits the direct
> access code instead. I know this sounds a little insane (turn the
> access into a message send and then auto-reduce it back to an
> access), but there is some method to the madness :-)
Jodrey School of Computer Science
Nova Scotia, Canada, B0P 1X0
fax: (902) 585-1067
voice: (902) 585-1467
> Hey, it's monday, I haven't woken up properly yet!
It must take you a couple of days because its Tuesday
where I am (and all of the world by now) <gg>