andreas.raab at gmx.de
Sun Sep 18 00:17:10 UTC 2005
David T. Lewis wrote:
> Well, if you can accept that "(2 + 3 * 4) ~= (2 + (3 * 4))", you should
> not be deeply disturbed to find that "16r1E4 ~= 16r1e4".
If you'd know me a little better, you would probably know that the
unfortunate effect that "(2 + 3 * 4) ~= (2 + (3 * 4))" disturbs me
deeply, too. It's simply bad user interface design to ignore what your
users already know and have been growing up with. And no, you don't have
to "accept" it if you know what you're doing since you can use
parenthesis and reordering. For example, I tend to write linear
interpolation as "(end - start) * t" although the parens aren't
required. But at times the precedence rules *still* get me, even after
using Smalltalk for more than ten years. And I tend to use *more*
parenthesis rather than *less* as some might expect, since I do happen
to look at and use other languages which get precedence right and it
confuses the hell out of me to switch between precedence rules.
> This appears to
> be a well established convention for Smalltalk (it works that way in e.g.
> Squeak 2.4). It does have a nice internal consistency, and the behavior
> is well defined (albeit not well enough documented).
And because Smalltalk is the holy cow we can't possibly change anything.
Yes, I know. I've heard that tune so often... but anyways, I'll give it
one more shot: How about compatibility? In VisualWorks, for example, it
is indeed the fact that "16r1E4 = 16r1e4". Wouldn't it be nice if hex
constants written in VisualWorks can be *correctly* read into Squeak?
More information about the Squeak-dev