On Aug 25, 2008, at 12:34 AM, Peter Michaux wrote:
> On Sun, Aug 24, 2008 at 9:44 PM, Kris Zyp <[EMAIL PROTECTED]> wrote:
>
>> Desugared from:
>
>> class Point {
>> private var x = Math.random();
>> function getX(){
>> return this.x;
>> }
>> ...
>> }
>
> Is there any need for the "this."? Some languages allow "this.x" to
> get out from under the shadow of a local "x" inside "getX". I don't
> think it is necessary to be able to escape such shadowing and actually
> increases confusion. If a method is many lines long then the reader
> may forget that "x" is local and not the instance variable. I would
> just call the local variable "locx" or "xx" or something different. I
> would actually rather see the "this." shadow escaping be disallowed.
That might be a good idea.
The bigger question is whether |this| remains at all. The desugarings
we tend to write on whiteboards use |let self = ...| or similar and |
self| as the new |this| -- but of course that might collide with a
necessary inner or outer name. It would be better to gensym the name,
but who has time at a whiteboard?
To refer to the instance in the sugared language, and there are valid
use-cases for doing so, we should use |this|. There's no point in
introducing a new keyword. Which gets to a point you raise later,
about var in class being confusing. If class is the new, higher
integrity constructor function that induces instance-bound frozen
methods, etc., then its syntax (by the similarity principle I
adumbrated earlier) *should* mimic function:
class Point(x, y) { // parameters to constructor here
let r = Math.sqrt(x*x + y*y);
let theta = Math.atan2(y, x);
function getX() x;
function getY() y;
// etc.
}
var or const could be used too, because they can be used in function
bodies. Class body *is* constructor code. Similarity is good because
it builds on JS programmers' knowledge of functions, but provides
incrementally better semantics for the similar syntax. Programmers
get the carrot, not the stick of gratuitously different syntax.
It will take more than a 2D point class to make the case, but this
was along the lines of the Oslo discussions on the third day, to
desugar as Mark proposed on the first (and showed in his post at the
head of this thread).
> In the above code snip it seems that properties will be public unless
> listed as private. In the security world, whitelisting is considered a
> best practice as blacklisting can accidentally leave things out in
> public that should not be.
Not everything in JS is security-critical. JS is used in single-trust-
domain embeddings, but even on the web, the B&D programming by way of
the security root password to the tattered "just a scripting
language" constitution seems like a power-grab :-P. I mixed three
kinds of technical politics there, but they are all relevant.
Different parties are concerned about the common good, but we don't
all agree on the common good.
Python and Smalltalk don't have private methods by default (or at
all), just to pick two examples. Should classes as better
constructors have this bias?
I'm not saying "no", I reserve judgment. It seems to me much depends
on the module system, if there is one (and there had better be, since
in spite of being the inevitable source of addressing and loading
semantics, the <script> tag is not enough for in-language modularity).
> What about the following two options:
>
> class Point {
> private x = Math.random();
> public function getX(){
> return x;
> };
> }
Verbose, please pick a default. Making people type private all the
time is going to get old (if you think 'function' is too long...).
> var Point = class {
> private x = Math.random();
> public getX = function(){
> return x;
> };
> };
This shows a separable and good idea: first-class classes. BTW, you
probably want 'const Point = class { ... }', and 'class Point...'
should make a const binding by default (unlike a function definition
-- another upgrade).
Another separable point to debate: resolved, classes should freely
nest (in other classes and functions) and generate new entities each
time they are evaluated. Just like functions (ignoring or removing
the joined function object option from ES3).
> If only one option could be included I'd *much* prefer the final
> option as "var" could be changed to "let" so I control the class's
> scope better.
That's not to say we shouldn't have the named form of class, any more
than we shouldn't have named functions. Named functions are a special
form, as close to let rec as you get in JS. You can have mutually
recursive named functions call one another freely, making forward
refs, due to hoisting.
You also get the intrinsic name, useful for diagnostics at runtime
and harder to infer (really guess, worst-case pick the name of the
most relevant binding) for anonymous functions.
> In either of the last two cases, I imagine that the "Point" variable
> is pointing to a first-class class objects (which desugars to a
> constructor function) that I could pass around, yes?
Yes.
There are deeper waters to do with types, but this is enough for
classes. Other details need to be worked out, but this is enough to
chew on for now. Thanks,
/be
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
