<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: Eliminating assignments and variable syntax
(acces</title></head><body>
<blockquote type="cite" cite>....It seems more like a hint to the
compiler than an<br>
aid to the human.&nbsp; Also, if := is eliminated how is a reference
assigned to<br>
a temporary variable?&nbsp; I suspect there's much here I'm not
seeing...<br>
</blockquote>
<div>I also vote for elimitating direct variable accesses and
assignments from the syntax (at least in the blue plane - so far they
could be left in next-generation Squeak for &quot;backward
compatibility&quot; reasons;-). The same effect with sufficient
clarity of syntax may be accomplished by message send syntax.<br>
</div>
<div><b>Variables in general:</b> other objects in the system which
have to be known by the receiver (self) in its methods by name (more
precizely: in its actions = contexts, running methods after receiving
a message). First token from the expression means such identification
of the first receiver in the expressions; all subsequent tokens are
messages send to the result of the previous message send. At the
moment, all primary receivers are being assigned in compile-time by
the compiler as variable accesses or acceses to the value of an
association (by specialized byte codes). An expression where the
receiver should be identified in run-time by name has to ne coded in
an explicit way - e.g.<br>
</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<tt> (Smalltalk at:
#Key) doThisAndThis</tt><br>
</div>
<div>The semantics behind the variable access is approximately the
following (when compared to real-world situations, nouns in sentences,
real-world contexts etc.):<br>
</div>
<ul>
<li>the name is first looked up in the context -<i> i.e. among
temporary variables declared in the method,</i> then (if not found) -&gt;
<li>it is looked up among own (private) attributes of the object -<i>
i.e. among the instance variables</i>, then (if not found) -&gt;
<li>it is looked up in the common attributes known to the object as a
particular kind -<i> i.e. class variables</i>, then (if not found) -&gt;
<li>it is looked up in categories I know or I belong to -<i> i.e. in
Smalltalk, or hierarchiocal namespaces (if available)</i>, then (if
not found) -&gt;
<li>error message is sent.<br>
</ul>
<div>Hence, in general access or modification of any variable would be
done by a message sent syntax<br>
</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<tt> name
doSomething</tt><br>
or<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<tt> name: newName</tt><br>
</div>
<div>just as if it would be sent to thisContext:<br>
</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<tt> thisContext name
doSomething&nbsp;</tt> or&nbsp;<tt> thisContext name:
newName.</tt><br>
</div>
<div>If thisContext knows the variable (i.e. it is a temp var), it is
accessed or assigned new value. If not, the access it delegated to the
receiver, i.e. to self. For self,&nbsp; ist vars are accessed and if
not found, a message is send to self (e.g. to find a<i> derived
attribute</i> by a method). Finally, the receiver's class can help
with accessing clacc vars and globals.<br>
</div>
<div>In the &quot;optimized way&quot;, accesses to temp vars would be
done in the same way as now (albeit, with a &quot;message sent&quot;
syntax). Accesses to inst vars as well, if not found amont the inst
var names, a message send to self would be generated. In this uniform
way, all class vars, pool dicts and globals may be handled.<br>
</div>
<div>Accessor and mutator methods and message send would work in the
same way - simply you have to write explicitely<br>
</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<tt> self myName
doSomething</tt><br>
</div>
<div>(in the same way as today;-)).<br>
</div>
<div>BTW, all possible typing errors may be found in the same way as
today - simply the compiler does not report an error, but rather a
warning, that such a name had not been found among the temp vars, inst
vars, class vars etc. and will be resolved in run time (...
continue/cancel...). If the class does not implement such method, the
warning may be even harder ;-).<br>
</div>
<div>So far, these issues target only the syntax and compilation.
Later, more advanced issues like &quot;really&quot; private methods
(another methodDict or reserved selector prefix), access and mutation
control for selected variables (e.g. for constraints) and similar
could be discussed and implemented.<br>
</div>
<div>Still, two different compilers might be available for developers
meeting their preference: the &quot;old&quot; one and the
&quot;self-like&quot; one (set e.g. in the preferences of the project
or in the browser or class).<br>
</div>
<div>-----<br>
</div>
<div>Basically, these issues target our current work on namespaces. At
this time, we don't intend to make such changes for temp vars and inst
vars (this is not the question of namespaces which have to serve for
globals and pool dicts, but it has to do with the basic Smalltalk
syntax as such).<br>
</div>
<div>However, in my opinion, in the context of name spaces, for
&quot;capitalized&quot; variables (class, pool dict and global) which
are being accessed not directly, but via an association, the
&quot;late binding of variable&quot; and hence generation of a message
sent instead of an assoc access bytecode has many advantages.<br>
&nbsp;<br>
</div>
<div>Augustin Mrazik<br>
</div>
<div>P.S. We are delayed a little bit with the namespaces - the first
version will be released this Thursday.<br>
&nbsp;<br>
&nbsp;</div>
</body>
</html>