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]
instead of
a := ''. b := ''. c := ''. etc.
Ivan
Thanks for taking the time in looking over my (admittedly pretty rough) idea.
From: "Jarvis, Robert P." Jarvisb@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
versus
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 myInstanceVar:newValue.
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 :-)
Regards,
Marcel
Ivan Tomek,
Jodrey School of Computer Science Acadia University Wolfville, 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>
8-)