[ENH] Display := when pretty printing([sm][et][er][cd][approved])

Peter van Rooijen squeak at vanrooijen.com
Fri Oct 17 23:37:37 UTC 2003


From: "Ned Konz" <ned at bike-nomad.com>
> On Friday 17 October 2003 3:06 pm, Peter van Rooijen wrote:
> > > Changing the shape of a class will cause it to be re-compiled, as will
> >
> > adding
> >
> > > a class variable.
> >
> > Ned,
> >
> > I mean, show me code. I want to see what you mean, because I thought
there
> > could not be a problem, including under recompilation if a class
definition
> > is changed. Just one example scenario where ambiguity would arise would
> > already be helpful.
>
> I'm not sure, but consider this:
>
> suppose we have an old method:
>
> SomeClass subclass: ClassA (instance variables x and y)
> someMethod
> ^x_y "same as 'x := y'"
>
> then we change the meaning of embedded underscores but don't re-compile.
The
> meaning of ClassA>>someMethod remains unchanged.
>
> Now a parent of SomeClass adds an instance variable called 'x_y'. This
causes
> the hierarchy to be re-compiled, changing the meaning of
ClassA>>someMethod.

The meaning is not changed, because the method is now ambiguous. I believe I
covered this in my original story, reproduced below.

Cheers,

Peter van Rooijen
Amsterdam

-------------------
x_y z would only be problematic if all three of x, y, and x_y were in scope,
right? Otherwise, there would be no ambiguity. So, only in the particular
circumstance of all three names being in scope, would one need to
disambiguate by either putting whitespace next to the _ or, alternatively,
use := for the assignment. In all other cases, there is no ambiguity anyway.

In view of the fact that existing Squeak code can't use identifiers with
underscores in them, it seems to me that _all_ existing code would still be
valid if underscores in identifiers would be allowed from now on.

And in new code, those who like to assign with underscores with no
whitespace around them, can even continue doing so, as long as they don't
have x, y, and x_y in scope, which might well mean that they will never
write an unintended ambiguity in their entire careers. Should it happen
anyway, a simple space will suffice to clear things up.
-------------------

> -- 
> Ned Konz
> http://bike-nomad.com
> GPG key ID: BEEA7EFE
>
>
>



More information about the Squeak-dev mailing list