Re: default constructors and implicit super() insertion

[Brendan Eich]

On Jun 22, 2007, at 2:20 PM, Peter Hall wrote:

> I can't see much about this on the wiki export, and it is barely
> touched on here:
> http://www.mozilla.org/js/language/es4/core/ 
> classes.html#superconstructor

That's way out of date, it goes back to the post-Edition 3 period  
where Waldemar Horwat was leading the charge. It's not relevant to  
the current work exported at http://developer.mozilla.org/es4/ and  
available as reference implementation with trac bugsystem at http:// 
ecmascript-lang.org/.

Sorry to say that http://developer.mozilla.org/es4/spec/spec.html is  
also pretty stale, but there is a plan to revamp it in the short run,  
yielding a skeleton with a few pieces of meat on the bones, before  
the next wiki export.

I'll duck your main points and let Jeff and others answer them ;-).

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: default constructors and implicit super() insertion

[Brendan Eich]

On Jun 22, 2007, at 3:11 PM, P T Withington wrote:

> I've always wondered what the point of carrying over C++'s
> constructor syntax was.

Ignoring the old pre-historic ES4 spec cited by Peter, I have to  
apologize again for:

http://developer.mozilla.org/es4/proposals/nullability.html

being out of date. The syntax we've settled on is not C++-like to  
that degree. It looks like this:

class C {
 var x : Object!
 var y : int

 function C(initialX : Object!, initialY : int)
   : x = initialX, y = initialY
 {
 ...
 }
}

A few points:

1. The purpose of this syntax is to ensure that class vars of non- 
nullable type are known to be initialized, with no chance for an  
uninitialized error that would be the dual of the null pointer  
exception (the exception that we hope to avoid via non-nullable  
types), while not requiring definite assignment or any other such  
analysis.

2. The = assignment operator is used as elsewhere, to allow  
destructuring assignments to set non-nullable vars. To avoid  
confusion with other kinds of initialization, we call these  
assignment expressions in the head of the constructor "settings",  
"class settings", or "constructor settings".

3. The scope chain for the right-hand side of each = includes the  
formal parameter names but not the new |this| object, while the scope  
chain for the left-hand side includes |this| but not the formal  
parameters. So the above could be simplified:

class C {
 var x : Object!
 var y : int

 function C(x : Object!, y : int) : x = x, y = y
 {
 ...
 }
}

4. An alternative syntax inspired by OCaml was:

class C(ax : Object!, ay : int) {
 var x : Object! = ax;
 var y : int = ay;

 function C {
  ...
 }
}

but this is too far from existing syntax and scoping (see http:// 
developer.mozilla.org/es4/discussion/nullability.html).

Anyway, settings are implemented in the reference implementation  
available at http://ecmascript-lang.org/ -- try them out and file  
bugs at the trac if need be (look for existing tickets on the same  
issue first). Thanks,

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Function Constructors as a type?

[Brendan Eich]

Functions are objects (instances), not types. Any new F given  
function F(){} must return an Object, as in ES1-3.


You can write function types of course, they are structural types:

type F = function (int, double, string):Object;

The usual subtyping rules apply, with sane extensions for optional  
and rest parameters. An update to spec/type_system.html is coming  
soon, and look for spec/type_relations.html too (under http:// 
developer.mozilla.org/es4/).


/be

On Jun 26, 2007, at 1:51 PM, Kris Zyp wrote:


Is it possible to use a function constructor as a type? For example:
function F() {}
var f : F = new F;
I assume this is not allowed, although I would think it would be  
nice if it were allowed, but I can't seem to find anywhere in the  
spec where this is explicitly stated and t he current reference  
implementation goes into an infinite loop when this is executing, I  
assume that is not the intended behavior :).

Kris
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss


___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: default constructors and implicit super() insertion

[Brendan Eich]

On Jun 26, 2007, at 4:43 PM, Sho Kuwamoto wrote:

> Just curious...
>
> In modern compilers, can't the compiler issue an error if the
> non-nullable member was (a) not initialized in the constructor, or (b)
> used before it was set?

See the bit I wrote about "definite assignment ... analysis". Indeed  
modern compilers can do many analyses, but this is JavaScript. It has  
to be easy to implement on cell phones. It cannot spend a lot of  
time, even ignoring device-imposed code size constraints, in  
compiling downloaded code.

> I've always hated the C++-style member initialization syntax and it
> seems like a shame to add it if it could be avoided.

C++-style member initialization is being avoided. That is, you don't  
see 'C(ax, ay) : x(ax), y(ay) {}' in the constructor. It's true that  
we are using : after the parameter list of the constructor function,  
but that's unambiguous (because you can't write a return type  
annotation for a constructor).

So, what do you mean, if not the : as the punctuator that introduces  
the settings? And why the hate? This corner case with one character  
in common with C++ syntax does not make the whole case "C++-style  
member initialization".

> Shouldn't it also
> be a goal to make sure that ES4 is less baroque and easier to learn  
> than
> C++?

Remember that these "settings" are required only if you use non- 
nullable types for class variables that must be initialized.

Asking a question that smuggles your (unjustified) conclusion that  
this particular corner case is "baroque" is no fair. Let's define  
baroque carefully, without emotion ("hate") and whipping-devils (C++).

/be

>
> Just my 2c.
>
> -Sho
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Brendan Eich
> Sent: Friday, June 22, 2007 6:41 PM
> To: P T Withington
> Cc: Peter Hall; es4-discuss
> Subject: Re: default constructors and implicit super() insertion
>
> On Jun 22, 2007, at 3:11 PM, P T Withington wrote:
>
>> I've always wondered what the point of carrying over C++'s  
>> constructor
>
>> syntax was.
>
> Ignoring the old pre-historic ES4 spec cited by Peter, I have to
> apologize again for:
>
> http://developer.mozilla.org/es4/proposals/nullability.html
>
> being out of date. The syntax we've settled on is not C++-like to that
> degree. It looks like this:
>
> class C {
>  var x : Object!
>  var y : int
>
>  function C(initialX : Object!, initialY : int)
>: x = initialX, y = initialY
>  {
>  ...
>  }
> }
>
> A few points:
>
> 1. The purpose of this syntax is to ensure that class vars of non-
> nullable type are known to be initialized, with no chance for an
> uninitialized error that would be the dual of the null pointer  
> exception
> (the exception that we hope to avoid via non-nullable types), while  
> not
> requiring definite assignment or any other such analysis.
>
> 2. The = assignment operator is used as elsewhere, to allow
> destructuring assignments to set non-nullable vars. To avoid confusion
> with other kinds of initialization, we call these assignment  
> expressions
> in the head of the constructor "settings", "class settings", or
> "constructor settings".
>
> 3. The scope chain for the right-hand side of each = includes the  
> formal
> parameter names but not the new |this| object, while the scope  
> chain for
> the left-hand side includes |this| but not the formal parameters.  
> So the
> above could be simplified:
>
> class C {
>  var x : Object!
>  var y : int
>
>  function C(x : Object!, y : int) : x = x, y = y
>  {
>  ...
>  }
> }
>
> 4. An alternative syntax inspired by OCaml was:
>
> class C(ax : Object!, ay : int) {
>  var x : Object! = ax;
>  var y : int = ay;
>
>  function C {
>   ...
>  }
> }
>
> but this is too far from existing syntax and scoping (see http://
> developer.mozilla.org/es4/discussion/nullability.html).
>
> Anyway, settings are implemented in the reference implementation
> available at http://ecmascript-lang.org/ -- try them out and file bugs
> at the trac if need be (look for existing tickets on the same issue
> first). Thanks,
>
> /be
>
> ___
> Es4-discuss mailing list
> Es4-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
> ___
> Es4-discuss mailing list
> Es4-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: default constructors and implicit super() insertion

[Brendan Eich]

On Jun 26, 2007, at 6:32 PM, Graydon Hoare wrote:

> The committee's feeling was that definite-assignment analysis -- what
> you're describing -- is too expensive, especially for lightweight
> compilers. It might be that any lightweight compiler is actually going
> to run in standard mode all the time anyways, and we might not make
> standard mode obliged to detect failure-to-initialize-non-nullable  
> until
> ctor execution time, in which case there's no "analysis", just a  
> runtime
> bit. I do not have deep feelings either way, and I'm not sure  
> whether we
> decided to support settings lists before or after our notions of  
> strict
> and standard modes had fully formed.

The bias was against definite assignment analysis being required for  
strict mode, never mind good old standard mode, which can as Graydon  
notes detect uninitialized non-nullable properties the hard way at  
runtime, but before the ctor returns an instance whose properties  
must be well initialized.

Perhaps for strict mode we could require DA analysis. If so, we could  
get rid of settings as special syntax. But settings relieve a cost  
not only to implementors -- they also (idiomatic and possibly hated  
syntax aside) require users of non-nullable types to put  
initialization front and center, not possibly obscured or missed in  
the ctor's body's control flow.

> Anyone want to chime in? I suspect a couple of the people with  
> opinions
> are presently or shortly on vacation...

Indeed. We'll hear back in a few weeks, if not sooner, from some  
group members now on vacation.


>> BTW does anyone have any thoughts on my original questions?
>
> Automatic inference of the default ctor signature and default super- 
> call
> from the superclass would be fine by me. I'm not sure what other  
> people
> think. It'd break AS code.

Peter, could you remind me how super and subclass ctor parameter  
lists would be related? There's no necessary relation. How would this  
work, other than as a convention supported by default, requiring  
overriding to avoid type or argument number errors?

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: default constructors and implicit super() insertion

[Brendan Eich]

On Jun 26, 2007, at 9:36 PM, Peter Hall wrote:

>> Automatic inference of the default ctor signature and default  
>> super-call
>> from the superclass would be fine by me. I'm not sure what other  
>> people
>> think. It'd break AS code.
>>
>
>
> I don't think it would break AS code. The only places where the
> behaviour would be different, are places that would currently be a
> compile error. (Unless I missed something, which is possible at this
> time in the evening)

Oh, I see:

class B { function B(a:int){...} ... }
class C extends B { function C(a:int,b:string):super(a){...} ... }

class B { function B(a:string){...} ... }
class C extends B { function C(a:int,b:string):super(b){...} ... }

class B { function B(a:int){...} ... }
class C extends B { function C(b:string):super(42){...} ... }

So why not relieve the programmer from having to write super(a) in  
the first case. Presumably the matching would be type equality for  
all superclass constructor parameter types. It would be an error to  
leave out an explicit super call if the subclass constructor had  
fewer or differently typed parameters.

Seems safe, helps what may be a common case (I don't know -- anyone  
with Flex experience have a count of classes this would help?).

/be


___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: default constructors and implicit super() insertion

[Brendan Eich]

On Jun 26, 2007, at 6:58 PM, Brendan Eich wrote:

> The bias was against definite assignment analysis being required for
> strict mode, never mind good old standard mode, which can as Graydon
> notes detect uninitialized non-nullable properties the hard way at
> runtime, but before the ctor returns an instance whose properties
> must be well initialized.

Just to follow up on my own point: Dave Herman reminded me that we  
don't want the evil twin of the NullPointerException, to wit an  
UninitializedNonNullableTypeError (or something with a shorter  
name ;-), rising to haunt the new language. Consider:

use standard;

class C {
   private var x : Object!;
   function C(y) {
 let q = helper(y);
 x = {p: q};
   }
   private function helper() {
 /* who knows what this does! */
   }
}

The constructor function for C does not know what helper does with | 
this|. Could it reference x? If so, it would have to get that pesky  
UninitializedError, which would seem no better than its dual, the NPE  
we hope to banish from runtime once instances containing non-nullably- 
typed vars are initialized.

Settings allow us to restrict not only when non-nullably-typed  
variables are initialized, but how their initializers run --  
specifically, without access to |this|. So any helpers would have to  
be static or outer (global, package internal) functions.

This seems like a better design both for non-nullability as a usable  
feature, and for simpler, smaller, faster implementations. It's true  
that it requires dedicated syntax, but that is just a "UI" corner  
case -- not unlike graphical UI settings that you don't often need,  
but can't live without in a crunch.

/be


___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: default constructors and implicit super() insertion

[Brendan Eich]

> While I see that it can be useful, I remain concerned that this will
> seem confusing to novices. Why do I need that colon? What does "x=x"
> mean? Why did I get the wrong result when I did the following, which
> looks a lot like the above?
>
>   // novice error 1
>   class C {
> function C(x, y) {
>   x=x;
>   y=y;
> }
> var x, y;
>   }

One could argue that novices will be baffled by a great many things,  
not only in ES4 (classes, non-nullable type annotations) but in ES3  
(higher order functions, with statements, eval dynamic scope, etc.  
etc). Novices learn, sometimes after bruising a toe or finger.

To argue briefly against your point in particular: settings are odd- 
looking, distinguished syntax for several reasons, including so that  
the scope for LHS and RHS can differ usefully.

To take your position, this is the only such case, and it could be  
misleading, or at best a useful but odd little feature hanging on  
otherwise fairly simple rules for mentally evaluating = operators  
near or within class constructors.

> What happens when an initialization requires a bit of logic? Suppose I
> have a "title" property of a MyDocument object that is non- 
> nullable. If
> the name is passed in, it is used. Otherwise, one is generated (e.g.,
> "Untitled1").

The ?: operator stands ready! Seriously, there's no problem using  
arbitrary expressions, including calls to static or outer-scope  
helper functions.

> I'm not really an expert, but in terms of overall simplicity, my
> preference is
>
>a) provide a clear way to disambiguate between members
>   and other variables in scope in *all* cases. (this may
>   already exist)

As for non-class functions (where |this| is *not* on the scope chain  
implicitly), |this.x| works.

>b) allow non-nullable types to be initialized in the
>   constructor in the body of the constructor, as
>   opposed to creating new syntax

Then the UninitializedError hazard arises, the dual of the NPE. True,  
it is limited in extent (duration, ... not sure what the right word  
is here) to the activation of the ctor. But given non-nullable type  
annotation syntax, why not have syntax (remember, "UI") specialized  
to avoid the UE hazard altogether?

>c) make it a *runtime* error to read an unitialized
>   non-nullable object. also make it a runtime error
>   to leave a constructor without having initialized
>   each non-nullable field.

This point (c) is really two points: make it a runtime error to read  
an uninitialized non-nullable slot; and a restatement or elaboration  
or implication of point (b). Taking just the first point as (c), you  
are saying what must be the case no matter what, unless we do require  
DA and make it an error not to initialize instance vars in  
constructors. No argument there.

>d) optionally, make it a compile-time error to exit a
>   constructor without having initialized each
>   non-nullable object.
>
>// my preferred syntax:
>class Position {
>   var x: Number;
>   var y: Number;
>   var target: Object!;
>
>   function Position(x: Number, y: Number, target: Object!)
>   {
>  this.x = x;
>  this.y = y;
>  this.target = target;
>   }
>}

"optionally" here could mean strict mode. It should not mean standard  
mode. It should not mean "implementation defined". We want a  
normative spec for both optional-at-implementation's-discretion  
strict mode, and for standard mode, in order to uphold interoperation.

> If this discussion is already closed or if I am barking up the wrong
> tree, please feel free to just say so. Thanks.

Not at all, this list exists exactly for this kind of discussion. So  
thanks back!

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: default constructors and implicit super() insertion

[Brendan Eich]

[Jumping in on one point only, I'll hope to help Lars get back to  
vacation so he can reply in full later :-P]

On Jun 27, 2007, at 12:00 PM, Peter Hall wrote:

>> For JS, this means
>> having a straightforward compiler that performs the minimum amount of
>> analysis, incroporating quick-and-dirty code generation, and so on.
>> (Strict mode may be beyond such an implementation.)
>
> I was under the impression that this discussion would not apply in
> non-strict mode. Would it be an error to not initialize a non-nullable
> variable in non-strict mode?

Yes, otherwise you have just renamed NPE to UE for no win, and then  
what's the point of non-nullable types.

The intuition should be familiar to anyone who has written fast low- 
level C or C++ code. Your instance has pointer members, they are  
guaranteed non-null by the constructor or an initialization routine,  
any failure during constructor/initialization propagates and disposes  
of the half-initialized newborn. Thus all methods post initialization  
need never check for null, and you never get a null pointer crash.

This is common, even required (certainly in kernel land -- I used to  
be a Unix kernel hacker).

Non-nullable types should capture this use case. They ought to  
eliminate stupid NPEs that I've seen (and still see) from Java and C#  
web apps. Even though those languages have more fancy analysis than  
we are proposing for ES4, their type systems still cannot rule out an  
NPE statically or otherwise.

So we really do want non-nullably-typed class vars to be initialized  
by the time the constructor finishes, and as Dave Herman reminded me,  
the settings design goes further: it avoids UEs while the constructor  
is active, by forcing non-nullably-typed vars to be set early, and  
without reference to |this| or to other non-nullable vars.

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: delegating to typed objects

[Brendan Eich]

On Jul 2, 2007, at 9:21 AM, Kris Zyp wrote:

It appears (at least in the reference implementation) that one  
there is an object that has a delegate object that is a typed  
object, that overwriting members in the top instance is sometimes  
not possible. For example:

class C { var x : String; }
c = new C;
function F() {}
F.prototype=c;
f = new F; // f.__proto__ = c
f.x =4;
If you do this c.x now equals "4", that is the value is not set in  
f, but it goes up the prototype chain and sets 4 into x (and does  
implicit conversion). I think I realize why this is being done. c  
is of type C, but f is not of type C, but it still must maintain  
consistency in the typing of its members (so instance method can be  
assured of the right types, I presume). However, this seems that  
like quite unintuitive behavior for JavaScript. Generally one would  
expect the statement f.x=4; to only affect f, not f's delegate (c).  
Was it ever considered to enforce a system where if f delegates to  
c, that f must be the same type (or subtype) as c? This could be  
done by allowing [[Class]] definition to be inheritable from a  
delegate (in this f would not define what [[Class]] it is, but  
would inherit it's class definition from c which defines it's class  
to be C), and maintaining prototype chain consistency with class  
inheritance.



If you want x to be a delegated and override-able "plain old"  
property, not a fixture, declare C thus:


class C { prototype var x : String; }

Without prototype qualifying var, you get a fixture, and fixtures are  
always fixed as to meaning and type constraint by type of their  
containing class. That's their raison d'être.


Having said that, I'll admit that your suggested change to the class  
instantiated by (new F) given F.prototype = new C is interesting and  
provocative. By default, ES4 as reference-implemented follows ES3 and  
makes (new F) for all functions F creates a new Object instance. But  
native constructor functions and classes can make instances of  
narrower types than Object, obviously (Date, RegExp, etc.). And some  
built-in classes (at least RegExp per ES3's spec, although no  
browsers follow this) have *prototype* properties of type Object.


So there's an attractive symmetry in making F.prototype = new C cause  
(new F) to instantiate C instances.


If we did this, you would still have fixtures overriding prototype  
properties, but you would have a fixture per (new F) instance, not  
one in the (new C) prototype instance as in your example (the one  
denoted by the variable |c|). That would avoid the pigeon-hole  
problem. (You could also use the prototype qualifier as in my counter- 
example.)


If we did this, you might also (or might not) want |dynamic| in front  
of class C {...} in order to allow "expandos".


Still thinking, comments welcome.

/be___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: delegating to typed objects

[Brendan Eich]

On Jul 9, 2007, at 12:10 PM, Jeff Dyer wrote:


class C { var x : String; }
c = new C;
function F() {}
F.prototype=c;
f = new F; // f.__proto__ = c
f.x =4;

If you do this c.x now equals "4", that is the value is not set  
in f, but it goes up the prototype chain and sets 4 into x (and  
does implicit conversion).


This behavior is incorrect. For compatibility with ES3, property  
writes must be shallow.


Agreed, but the question is: how? If you say that f.hasOwnProperty 
('x'), then what is the type constraint on that property's value? If  
it is String, then how is it implemented given that new F creates an  
Object instance, not a C instance?


One could imagine a fixture being added to each Object instance  
created by new F. It would make the type of f be {x:String}, which is  
compatible with C assuming you put 'public' in front of 'var  
x' (that's necessary, otherwise the x in c is in C's internal  
namespace -- please correct me if I have this wrong).


What's not allowed is an unconstrained slot on f -- that would break  
type safety for methods of C that count on x being a String. What  
also seems hard to believe in is some magic getter/setter pair in c  
(f.__proto__) that lets x be stored in each instance (f) but enforces  
the type constraint.


So when you wrote "This behavior is incorrect", did you have in mind  
a fixture per instance, created on demand when assigning ("writes  
must be shallow") to x where f.__proto__.x is a fixture defined by C?  
I.e., a copy-on-write fixture due to the class of f differing (and  
lacking any public::x of its own) from the class of c?


If you want x to be a delegated and override-able "plain old"  
property, not a fixture, declare C thus:


class C { prototype var x : String; }

To be clear, in the example above this would put a expando property  
‘x’ on ‘f.__proto__.__proto__’.


Yes, but it could be shadowed in f instances, inheriting the type  
constraint.


See my comment before my last one. Making prototypes more like  
classes would make them less flexible, more complicated, and  
duplicate functionality that is already available. I don’t see the  
point, but maybe I’m missing the use case.




Using functions as extra constructors may be a use-case, but the  
primary problem is definitional: given functions and classes, what  
*should* happen in Kris's example, and how should it be specified/ 
reference-implemented? Copy-on-write fixtures are a new thing under  
our Sun, it seems to me.


/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: delegating to typed objects

[Brendan Eich]

On Jul 9, 2007, at 2:19 PM, Jeff Dyer wrote:

See my comments above. There is no need for copy on write  
fixtures,  just a plain old expando on ‘f’ for ‘x’.


Ok, I see your point.


If you want type guarantees, use classes.


Rather, use classes or structural types only, not constructor  
functions that delegate to class instances. Or if using constructor  
functions that delegate to class instances, use prototype methods in  
the class to unbind |this|, and make sure those methods either (a)  
are generic or (b) enforce the necessary |this| type constraints.


A bit of a mouthful compared to your statement. :-/

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: delegating to typed objects

[Brendan Eich]

On Jul 9, 2007, at 3:22 PM, Jeff Dyer wrote:


 On 7/9/07 2:42 PM, Kris Zyp wrote:

It seems to me that transfering bound methods to the function  
instances makes the situation equally confusing:

Now if write:
class C { var x : String; function m() : String { return this.x }}
c = new C;
function F() {}
F.prototype=c;
f = new F; // f.__proto__ = c
f.x =4;
f.m() -> ???
A Transferred bound method would mean that when we call f.m(),  
that the "this" in the method execution is actually c and not f.  
Does that really make sense?


Agreed. This presents a usability hazard. It has been suggested  
that if ‘f’ is not compatible with class C, then an error should be  
raised.


Kris asks where such an error would be raised. I would be surprised  
if it were anywhere other than F.prototype = c, but that is odd given  
that one can write ES3 code that sets, e.g. F.prototype = new Date.


This might be an alternative that avoids the copying of fixtures or  
other class like inheritance mechanisms to ensure type safety.


In your "f.x expando w/o type constraint shadows c.x" counter- 
proposal, there's no type safety problem for fixed methods of C --  
they can't be extracted without remembering their |this| binding, and  
when called (e.g., f.m()) on an incompatible type you should get a  
type error because |this| is type-constrained (as well as instance- 
bound) for fixed methods. Prototype methods as always have to  
constrain the type of |this|, or leave it * and do their own generic  
programming or checking.


I think we have only two courses:

1. Kris's proposal to make F construct instances of C. If C is not  
dynamic, these instances can't be decorated with expandos by (new F)  
or its callers.


2. Your proposal to avoid any magic implication of F.prototype = c,  
leaving f.x setting an unconstrained expando, leaving fixed methods  
of C this-bound to c, etc.


I think 2 is simpler but surprising (again consider F.prototype = new  
Date in ES3), and I'm not sure how much simpler since the refimpl has  
managed to do something different from either of the above (call it  
0. Set c.x when evaluating f.x = 4).


Having thought about 1 more, I'd like to point out that it's *not*  
what ES3 does:


js> function F(){}
js> F.prototype = d = new Date
js> f = new F
js> f.__proto__ === d
true
js> f.setTime(0)
typein:10: TypeError: Date.prototype.setTime called on incompatible  
Object


So new F did create an Object instance, and it linked its __proto__  
(ES1-3 [[Prototype]] internal property) to d. Not what Kris proposes  
by analogy to ES1-3, so I'm favoring 2 at the moment.


/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: delegating to typed objects

[Brendan Eich]

On Jul 9, 2007, at 4:16 PM, Brendan Eich wrote:

> I think we have only two courses:
>
> 1. Kris's proposal to make F construct instances of C. If C is not  
> dynamic, these instances can't be decorated with expandos by (new  
> F) or its callers.
>
> 2. Your proposal to avoid any magic implication of F.prototype = c,  
> leaving f.x setting an unconstrained expando, leaving fixed methods  
> of C this-bound to c, etc.

Sorry, the "leaving fixed methods of C this-bound to c" is a red  
herring. It's true that extracting c.m or F.prototype.m would get a  
bound method reference which when called would bind |this| to c --  
but that's not relevant to a delegated call f.m(), which would try to  
pass f, and then run into the type constraint on |this| that's  
implicit in all fixed (non-prototype qualified) methods (functions  
defined in class bodies).

Hope this is all clear now :-P.

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: delegating to typed objects

[Brendan Eich]

On Jul 9, 2007, at 4:32 PM, P T Withington wrote:

> On 2007-07-09, at 19:16 EDT, Brendan Eich wrote:
>
>> Having thought about 1 more, I'd like to point out that it's *not*
>> what ES3 does:
>>
>> js> function F(){}
>> js> F.prototype = d = new Date
>> js> f = new F
>> js> f.__proto__ === d
>> true
>> js> f.setTime(0)
>> typein:10: TypeError: Date.prototype.setTime called on incompatible
>> Object
>>
>> So new F did create an Object instance, and it linked its __proto__
>> (ES1-3 [[Prototype]] internal property) to d. Not what Kris
>> proposes by analogy to ES1-3, so I'm favoring 2 at the moment.
>
> [Coming late to the party]
>
> And it has burned me that I could not do that.  I wanted to write an
> 'annotated string' and couldn't because of exactly this restriction.
> Will I be able to subclass built-in types?

Subclass, yes -- provided the superclass is not final.

Subclassing is not what's going on above, though.

>   Or will their methods be
> hard-wired in some way that raises similar issues?

Certainly not for two classes, one a subclass of the other. There you  
get the usual OOP object calculus.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: delegating to typed objects

[Brendan Eich]

On Jul 9, 2007, at 4:40 PM, Brendan Eich wrote:

>> And it has burned me that I could not do that.  I wanted to write an
>> 'annotated string' and couldn't because of exactly this restriction.
>> Will I be able to subclass built-in types?
>
> Subclass, yes -- provided the superclass is not final.

I should have added that String is not final in ES4 but string is.  
Yeah, we have had to add back primitive types -- they're wired deeply  
into the language. The pain should be less this time, though. And the  
final class string extends String, so you can decorate  
String.prototype with new function-valued properties and primitive  
strings can be operated on by those methods.

Similarly, boolean <: Boolean.

The current reference implementation makes {int,uint,double,decimal}  
<: Number, but we hope to change that while preserving backward  
compatibility, by making all of {int,uint,double,decimal,Number}  
peers and wiring up the prototype properties of the first four to the  
object denoted by Number.prototype. That's actually more compatible  
if you study it a bit. ES3 today (SpiderMonkey):

js> i = 42
js> i.__proto__ === (3.14).__proto__
true
js> i.__proto__ === Number.prototype

No extra layer of int.prototype between i.__proto__ and  
Number.prototype.

So we will make the same fix to boolean and string -- they won't have  
their own class prototype objects, rather they'll share their  
respective capitalized super-class's prototype. This means that  
boolean need not extend Boolean, nor string extend String, which will  
avoid some ugly bootstrapping magic.

People do use String and Number prototyping of primitive values  
(whether int or double), so compatibility is worth a special case  
here when setting up the built-in classes.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: delegating to typed objects

[Brendan Eich]

On Jul 9, 2007, at 4:51 PM, Kris Zyp wrote:

> You are right, it doesn't work for a Date, but it does work on an  
> Array.

Only if you don't call toString or toLocaleString.

Most Array and String prototype methods are intentionally generic.  
Too bad we didn't generalize this all over the place in 1996 (sorry,  
Tucker). To call such methods on other types of objects, in ES1-3 you  
have to use .apply or .call -- in ES4 there are Array.slice, .e.g.,  
counterparts that take a leading explicit this-object parameter for  
Array.prototype.slice.

> The incompatibility of calling setTime on the Date instance seems  
> to have more to do with the natural inclination to make primitives  
> classes "final" (I am not sure if they are in ES4, but in Java they  
> are final) than class method binding. While I am still hoping for  
> option 1, I will say that throwing an (incompatible object) error  
> on f.m() seems more consistent than the other possibilites that I  
> have been countering: non-shallow assignments, automatic this- 
> binding, or preventing the assignment of prototype objects that  
> happen to be instances of user defined classes.

Yeah.

/be


___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: delegating to typed objects

[Brendan Eich]

On Jul 9, 2007, at 9:09 PM, Kris Zyp wrote:

> I think it seems worth considering what a programmer is intending  
> if writes
> a function and defines a prototype for it. This is an explicit  
> action to
> create objects that inherit from the prototype object. If a user has
> specifically written code to inherit from c, wouldn't he expect to  
> inherit
> everything from c, including fixtures and methods (that work, not  
> throw
> incompatibility errors)?

Because it's possible to violate the type constraints on fixtures in  
the non-subclass object created by the function constructor?

That seems like a real possibility. The class methods, unless  
qualified by prototype, really do constrain the type of |this|, and  
that's a big part of the value of classes. Consider the alternatives:

1. Classes do not constrain types, have to check everything that  
might be different in a delegating object method call (|this|,  
members) at runtime.

2. Delegate creation via (new F) given F.prototype = new C and class  
C must make an instance of C, not of Object. This is not backward  
compatible.

3. Delegating to class methods from an instance created via (new F)  
somehow (how?) wraps the class methods with type-constraining  
wrappers, so the cost is not born by the class methods when called  
class instances.

I don't think any of these is a good plan.

> If we access fixture properties and methods just as
> we do do expando properties and functions, why wouldn't we expect
> programmers to want and fixtures and methods to be inherited?

Because fixture means fixed, unlike expando or ad-hoc properties. If  
you want to delegate without type constraints, you have the tools in  
JS already. Using classes means either locking down fields and  
methods, or (if you use dynamic and prototype qualifiers) emulating  
the ES1-3 builtins and stuff like the DOM classes. In the former  
case, you should get a type error. In the latter, you can do what you  
say you want, but you have to write the class with extra qualifiers.

> Defining
> prototypes is not something that just automatically happens in  
> places, but
> is a very intentional definition on the part of a programmer in  
> which they
> want and expect inheritance.

So is defining a class.

So is mixing the two definitions, constructor function prototype (not  
a definition but an assignment expression, of course) and class  
definition.

> And I still appeal to the symmetry and consistency of the "is"  
> operator
> operating exactly the same as the old instanceof operator when the  
> testing
> against a class:
> (a is C) == C.prototype is in a's delegate chain (at least when  
> __proto__
> has not been externally modified) that would be true with option 1.

The is operator tests whether its left operand is an instance of a  
subtype (<:, which is reflexive, so includes the type itself) of its  
right operand. It is not instanceof, which tests whether its left  
operand has a prototype equal to the value of the 'prototype'  
property of its right operand (if that operand is an object). Don't  
mention mutable __proto__ (it's a botch and irrelevant). Just consider:

function B() {}
function D() {}
D.prototype = new B
d1 = new D
assert(d1 is B)  // false
assert(d1 instanceof B)  // true
D.prototype = new Object
d2 = new D
assert(d2 is B)  // false
assert(d2 instanceof B)  // false

class B {}
class D extends B {}
d1 = new D
assert(d1 is B)  // true
assert(d1 instanceof B)  // true
D.prototype = new Object // silently fails because 'prototype'
  // is DontDelete and ReadOnly in D
d2 = new D
assert(d2 is B)  // still true
assert(d2 instanceof B)  // still true

Not only can't you modify D.prototype, but (d1 is B) is true for  
class B but false for function B.

You are right that is and instanceof agree in all four assertions for  
classes. But only one of four corresponding assertions for  
constructor functions is true. Classes are not functions, not by a  
long shot.

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: delegating to typed objects

[Brendan Eich]

On Jul 10, 2007, at 8:21 AM, Kris Zyp wrote:

> Because it's possible to violate the type constraints on fixtures in
> the non-subclass object created by the function constructor?
> Not if the instance of F is a instance of C.
>
> 1. Classes do not constrain types, have to check everything...
>
> Certainly don't want that. However, checking to see if an  
> incompatible method error needs to be thrown on every method call  
> requires extra checks as well doesn't it?

The class methods can't be extracted or called without this binding  
to the object from which they were extracted or in which they were  
found, so there's no type check. From the reference implementation:

 >> class C { public var x : string; public function m(y) { x = y } }
 >> c = new C
[object C]
 >> c.x = 42
42
 >> function F() {}
 >> F.prototype = c
[object C]
 >> f = new F
[object Object]
 >> f.x
42
 >> f.m(43)
 >> f.x
43
 >> c.x
43


>
> 2. Delegate creation via (new F) given F.prototype = new C and class
> C must make an instance of C, not of Object. This is not backward
> compatible.
>
> Why not make (new F) be an instance of C if C is a subclass of  
> Object, otherwise make it an instance of Object?

Every type is a subtype of Object except undefined (the type;  
undefined is the name of the type and its one value), so the  
otherwise to that if would never be taken.

>  That would maintain backwards compatibility wouldn't it?

No -- see SpiderMonkey excerpt from a previous message:

js> function F(){}
js> F.prototype = d = new Date
js> f = new F
js> f.__proto__ === d
true
js> f.setTime(0)
typein:10: TypeError: Date.prototype.setTime called on incompatible  
Object

>
> In the former
> case, you should get a type error. In the latter, you can do what you
> say you want, but you have to write the class with extra qualifiers.
>
>
> Type errors is what I want. I would want (new F).x = 4 to throw a  
> type error if x is defined as a String in C (or I guess if x is  
> defined as a String, ES4 fixtures cause an implicit type  
> conversion, at least in the ref impl, but type errors would surely  
> be in order at some point).

Wanting a type error instead of a conversion is a separate topic, so  
let's talk about it in another thread. See also

http://bugs.ecmascript-lang.org/ticket/113

Having long ago proposed separate is/as/to annotations for subtype- 
test-or-null, subtype-or-throw, and conversion, I'm not in favor of  
more than : annotations. And we need converting annotations to self- 
host ES1-3 builtins, the DOM, etc.  But please do start another  
thread if you can suggest something to handle that use case and the  
one you have in mind. First a statement of the use-case you have in  
mind would be helpful.

/be


___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Miscellaneous

[Brendan Eich]

On Jul 17, 2007, at 8:56 AM, Jason Orendorff wrote:

> On 7/17/07, Garrett <[EMAIL PROTECTED]> wrote:
>> I found this example:
>> http://www.mozilla.org/js/language/es4/rationale/ 
>> miscellaneous.html#typed-arrays

Garrett heard this, but just so the list knows: These old documents  
are being moved to new names without redirects, to break links and  
search engine page rank. They've misled too many people already.  
Sorry this didn't happen years ago.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: delegating to typed objects

[Brendan Eich]

On Jul 10, 2007, at 9:20 AM, Kris Zyp wrote:

>> The class methods can't be extracted or called without this  
>> binding  to
>> the object from which they were extracted or in which they were   
>> found, so
>> there's no type check. From the reference implementation:
> I thought we had agreed that |this| being c instead of f in f.m()  
> was too
> much of a usability hazard. I guess not (although I still think it  
> is).

It's an open issue. I sent one message making it sound like the RI  
does what you want now, but it just ain't so. Sorry for any confusion.

Here are the tickets I've filed:

http://bugs.ecmascript-lang.org/ticket/141
http://bugs.ecmascript-lang.org/ticket/142

Please feel free to comment.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: delegating to typed objects

[Brendan Eich]

On Jul 21, 2007, at 7:13 AM, Kris Zyp wrote:

> So does this mean that the verdict has been reached for whether or  
> not new
> objects from function constructors can be classes?

I pointed out that ES3 does not do what you seem to want here  
(functions as auxiliary constructors for classes). In ES1-3, new F  
always makes an Object. It doesn't matter if F.prototype = new  
String. So we're not going to change this incompatibly for ES4.

> It looks like from the
> bug report that |this| binding will occur to the class instance.  
> What is
> still open for comment?

Incompatible changes without new syntax to trigger them are beyond  
the pale. Other issues such as how |this| binds, a grand unified  
theory of |this| binding, are good trac ticket (and indeed es4- 
discuss first) fodder.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Date.parse return type

[Brendan Eich]

On Jul 23, 2007, at 10:23 AM, [EMAIL PROTECTED] wrote:

> In the public Date/time proposal, the Date.parse static method  
> returns a Date. This is a bit odd, because the current javascript  
> Date.parse method returns a number (nr. of ms since epoch). Is this  
> by design?

That's a mistake, which Lars noticed and corrected recently.

> Is there some compatibility-strategy defined? I couldn't find one...
>

The strategy is backward compatibility except in a few hard cases  
where the current (since 1997, ES1) semantics are so confusing and  
buggy that cleanups probably improve real-world code correctness. See  
http://developer.mozilla.org/es4/proposals/bug_fixes.html.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Separating a Hash type from Object

[Brendan Eich]

I can take maximum blame for advocating Dict over Dictionary, based  
on brevity and the Python type, transliterated appropriately  
(capitalized, I mean ;-).

But Hash is just as good by that crude metric.

We'll have another straw poll. Hash was mooted early on, but then  
Dictionary stuck, and later I urged brevity. Thanks for the reminder.

/be

On Jul 25, 2007, at 9:12 AM, Andrew Dupont wrote:

> Garrett wrote:
>> How does "Dictionary" sound?
>>
>>
>
> I like "Hash" myself. Just as short as "Dict," but easier to  
> pronounce,
> and sidesteps the camelCase ugliness. Prior art in Ruby (and many  
> other
> languages, I'm sure).
>
> Cheers,
> Andrew
> ___
> Es4-discuss mailing list
> Es4-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Separating a Hash type from Object

[Brendan Eich]

See Lars's post today. It's a parameterized type. So you can map  
however you please: Dict. or even Dict.<*,*>.

/be

On Jul 25, 2007, at 10:51 AM, P T Withington wrote:

> On 2007-07-25, at 13:36 EDT, Brendan Eich wrote:
>
>> We'll have another straw poll. Hash was mooted early on, but then
>> Dictionary stuck, and later I urged brevity. Thanks for the reminder.
>
> So a Dict is not a Map?  It's keys must be identifiers, not Objects?
> ___
> Es4-discuss mailing list
> Es4-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Date.parse return type

[Brendan Eich]

Same as ever (backward compatibility): NaN.

/be

On Jul 28, 2007, at 8:19 AM, [EMAIL PROTECTED] wrote:

> On 7/23/07, Brendan Eich <[EMAIL PROTECTED]> wrote:
>> On Jul 23, 2007, at 10:23 AM, [EMAIL PROTECTED] wrote:
>>> In the public Date/time proposal, the Date.parse static method
>>> returns a Date. This is a bit odd, because the current javascript
>>> Date.parse method returns a number (nr. of ms since epoch). Is this
>>> by design?
>>
>> That's a mistake, which Lars noticed and corrected recently.
>
> OK, that's clear. But does Date.parse("2007-07-28") raise a
> SyntaxError, or does it return NaN?
> -- 
> |\
> | \
> |_/oeke
> [EMAIL PROTECTED]
> ___
> Es4-discuss mailing list
> Es4-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Date.parse return type

[Brendan Eich]

On Jul 28, 2007, at 11:21 AM, Lars T Hansen wrote:


Date.parse("2007-07-28")


SpiderMonkey:

js> Date.parse("2007-07-28")
NaN

We've never had a bug filed asking for this to work because it works  
in IE (does it? I can't test atm). But anyway, Lars is right in  
general; my answer was based on Firefox only. Per the fine spec  
(since Edition 1 :-P), the result is implementation-defined.


/be___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Separating a Hash type from Object

[Brendan Eich]

On Jul 30, 2007, at 8:54 AM, Garrett Smith wrote:

> [overquoting deleted]

> var stuff = new HashTable.();
>
> stuff.add( "one", 1 );

s/add/put/

> stuff.hasOwnProperty( "one" ); // false.
> stuff.one;// undefined.
> "one" in stuff; // false.

Right.

> if( "one" in stuff.keys ) stuff.get( "one" ); // 1.
>
> for( var key in stuff.keys ) {
>   print( key + ": " + stuff[ key ] );
> }
> // one: 1.

Note: for (var key in stuff) is enough; for (let key in iterator::keys 
(stuff)) also works. You can iterate over values with

for each (let val in stuff) ...

And you can destructure items via

for (let [key, val] in iterator::items(stuff)) ...

for example. But this is all generic due to iterators and generators  
(whose last exported wiki page is way out of date).

> Should all Collections have a toJSONString?

Not necessarily, but that method delegates to Array.prototype or  
Object.prototype anyway, and as Lars noted the one in  
Object.prototype is generic. If it leaves out important properties  
due to the DontEnum attribute, that might be a clue that an override  
is needed. On the other hand there's no JSON type for Map, so you  
can't deserialize directly to a Map instance. You would have to  
convert using the |to| operator or a Map call or construction.

> Collection
>  |
>  +HashTable, SortedSet TreeMap ?

This is up to the larger ecosystem, but as with Python, the JS way,  
and the Web way (cf. mashups, which are not planned ahead of time to  
share named "types" broadly construed) favors protocols over single- 
inheritance nominal type trees. So collections might implement  
interfaces (either nominal, or more likely structural, types such as  
type iterator::IterableType).

 (I don't much care for "Dict" as a name myself, but BiCaptialized
 suggestions like HashMap and hashCode won't get you anywhere  
 with this
 committee ;-)

> The current JS spec is camelCasing everything. I usually like it when
> an API does one thing consistently. If it's underscores, then always
> use underscore, et c. JavaScript (hey, that's camel'd, too!) alway
> uses camelCase. The DOM stuff is consistent, too (textContent,
> nodeValue, et c). Will adding an inconsistency add confusion?

There's no inconsistency at all -- types are InterCaps, methods are  
true camelCaps. Just like Java, after Smaltalk.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Question about joined function object of ECMA-262 3rd edition

[Brendan Eich]

On Jul 31, 2007, at 5:41 AM, P T Withington wrote:

> Indeed.  I was suggesting that the spec was broken; that it meant to
> prescribe an optimization to avoid unnecessary closures, but that it
> got it wrong (perhaps because it overlooked the mutability of the
> function object itself?).  Surely backwards compatibility should not
> trump correctness?  You don't want to have to force users to contrive
> to create a closure just to be able to add properties to a function?

No, none of that (breaking backward compatibility, requiring closures  
for mutability) was desired.

I wasn't around for Edition 3 except for one or two meetings (pitched  
sharp variables and uneval/toSource), but I talked to Waldemar about  
this at some point. The goal was to allow an optimization that would  
be implementation dependent. I believe mutability was forgotten. So  
we should just remove all this joined function language.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: let/RAII

[Brendan Eich]

On Jul 31, 2007, at 12:49 PM, Won wrote:

> Greetings (my first post) --
>
> I'm pretty excited about the proposed changes coming up for
> ECMAscript. "let" in particular seems overdue. For better or worse, I
> have a C++ programming background, and one of the idioms that I find
> useful every day is RAII (resource acquisition is initialization),
> also called the "Dispose" pattern in other languages. When a variable
> falls out of scope (say, an object that contains a file handle), then
> a method gets called (e.g. close file handle). In particular, RAII
> makes exception-safe coding much more convenient.

You can use try-finally already in ES3 for exception-safe cleanup:

   let (i) {
 try {
   i = getinput();
   doit(i);
 } finally {
   cleanup(i);
 }
   }

But RAII means implicit cleanup on block exit, so this is not enough  
-- I just wanted to point it out in case someone on the list new to  
the language missed it.

> In C++, every object gets this treatment. Other languages have special
> syntax/forms, such as "using" in C#, "with" in Python and VB, and
> Ruby/Smalltalk has variables scoped in closure blocks.

The advantage of these approaches is the implicit close or exit  
automation.

The only thing on the charts for ES4 that could be used is the  
iterator protocol (wiki export at http://developer.mozilla.org/es4/ 
proposals/iterators_and_generators.html is unfortunately quite out of  
date, and we are moving the dokuwiki to http://ecmascript-lang.org/  
soon -- look there in a week or so):

function raii() {
   try {
 yield getinput();
   } finally {
 cleanup();
   }
}

for (let i in raii()) {
   doit(i);
}

This looks like a loop, which is confusing compared, e.g., to Python  
2.5's with statement. But it has the desired implicit close, if you  
squint hard and consider the generator function with its try-yield/ 
finally the equivalent in explicit declarative overhead to a Python  
object that has the necessary metaprogramming hooks (__enter__,  
__exit__ if memory serves), etc. for C++ (auto storage class instance  
where the class has a dtor that calls cleanup()).

We are now planning to automate close for all iterators, not just for  
generators, when started from a for-in loop, so you could write your  
own object implementing the iteration protocol, and avoid the  
generator function. But the generator function is probably shortest  
and it's built-in.

It wouldn't be hard to sugar this more, but we haven't considered any  
proposals in this area. Feel free to make one.

/be


___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: let/RAII

[Brendan Eich]

If you start it, it's up to you to call close on it. This was all  
worked out here in the thread with subject "Immediate closing of  
iterators" end of last year and early this year -- you posted a  
followup agreeing ;-).

/be

On Aug 1, 2007, at 6:05 AM, P T Withington wrote:

> On 2007-07-31, at 17:34 EDT, Brendan Eich wrote:
>
>> We are now planning to automate close for all iterators, not just for
>> generators, when started from a for-in loop, so you could write your
>> own object implementing the iteration protocol, and avoid the
>> generator function. But the generator function is probably shortest
>> and it's built-in.
>
> What happens when I call a generator function not in a loop?
> ___
> Es4-discuss mailing list
> Es4-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: What is "unit"?

[Brendan Eich]

Great questions. The proposal has evolved a bit, so please forgive  
the moving-target nature of the page available now at

http://wiki.ecmascript.org/doku.php?id=proposals:program_units

(BTW, this is the new and as far as I know world-readable location of  
the dokuwiki we've been using for proposals, discussion, and spec  
prototyping. It's almost read-only now, since the reference  
implementation, trac bug-ticket database, and real spec documents are  
more the collective source of truth.)

There's more work to do, including rationalizing and minimizing  
concepts including units and packages. A couple of notes:

A package is a named pair of namespaces (public and internal), some  
rules for using those namespaces within the package body, and some  
special forms for importing names from the package's public namespace.

Program units are compilation units, so unlike packages, which are  
never "closed" and can be extended in a given trust domain, units  
come to an end at the right curly brace.

/be

On Aug 10, 2007, at 2:29 AM, Shijun He wrote:

> I've read the presentation "The truth about
> JavaScript" experience-2007/>
> by Brendan, there are some code:
>
> use unit acme.widgets "http://acme.com/widgets";;
>
> unit acme.widget {
> // program unit definition goes here
> ...
> }
>
> What is the "unit" for? What's the relation of "unit" and "package"?
> ___
> Es4-discuss mailing list
> Es4-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Self type

[Brendan Eich]

On Aug 13, 2007, at 5:32 AM, Peter Hall wrote:

> I was just reading the Self type proposal for the first time
> (http://wiki.ecmascript.org/doku.php?id=proposals:self_type).

Cormac should reply authoritatively since he's the author of that  
spec, but I'll have a go.

> How should a compiler handle this keyword? Should it be able to
> substitute a concrete type at compile-time, or must the actual type be
> evaluated at runtime (possibly with varying results)?

Compile-time (see below).

> To give an example of what I am getting at, would the following be an
> error (in strict mode)?
>
> type A = {x:Self};
> class B extends A {}

You can't extend a structural type with a class. Note that the type  
definition just names the structural type, it does not make it a  
nominal type. So its uses can be substituted: class B extends  
{x:Self}, which is not legal.

> var b:B = new B().x; // error: can't implicitly coerce from A to B ??

In any event, the Self identifier is bound within the type expression  
{x: Self} (and we know it's a type expression because in this case  
it's in the right-hand side of a type definition) to the nearest  
enclosing object structural type.

> Or...
>
> function A (){}
> A.prototype.f = function():Self{
>return this;
> }

Self is bound only within object structural types, so this too is not  
legal.

> function B() {}
> B.prototype.f = A.prototype.f;
>
> Is this going to work as intended?
>
> Or can't Self be used outside of the sorts of usage found in the
> proposal examples?

That's it.

> Finally, on naming, I don't think it should be upper-case. It's a
> keyword, not an actual type. But even "self" , like the lexical
> "this", more suggests an instance not a type.

Hence the straw-man capitalized name.

> Perhaps "this type" might be clearer, and more akin to the "this
> generator" and "this function" that have been proposed elsewhere.

Not bad at a glance. Have to check for ambiguities. Thanks,

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Self type

[Brendan Eich]

On Aug 13, 2007, at 1:59 PM, Peter Hall wrote:

>>> Or can't Self be used outside of the sorts of usage found in the
>>> proposal examples?
>>
>> That's it.
>>
>
> In that case, I think it needs to be clearer about how the syntax can
> be used.

No doubt the proposal needs to be clearer to become a spec.

> Is it only for use as the "this" parameter for function
> types?

No, but it is only for function types within object structural types.  
See the "Use Cases" section:

 * clone, iterators: {f:function():Self}
 * binary methods, equals: { f : function(x:Self):boolean }
 * structural object methods: { f : function(this:Self, ...) } -  
only useful if structural objects with types

at http://wiki.ecmascript.org/doku.php?id=proposals:self_type.

Note that the "same type" case, equals, requires a runtime check to  
be generated. This eliminates the kind of instanceof or downcasting  
hand-written boilerplate seen in Java's equals implementations.

> Seems to me like it should be usable anywhere that the compiler
> can reasonably detect the type at compile-time.
>
> e.g.
> // this usage is handy for boiler-plate code that you can just copy
> // and paste without modification, or from an IDE code snippet  
> template
> class A {
> var a:Self;
> // or...
> // var a:this type;
> }

This is not a strong motivation IMHO.

> type B = {b:Self};

We don't allow recursive structural types in general, but this kind  
of degenerate cycle might be ok. Cormac should comment.

> Other places where special treatment of the keyword would be useful is
> in interfaces, where the a function argument or return value should be
> the same as the type:
>
> interface IClonable {
> public function clone():Self;
> }
> class A implements IClonable {
>   public function clone():A { return new A() };
> }

Indeed -- those are use-cases for interfaces and classes as well as  
for structural types. However, the proposal is focused on structural  
types since unlike classes, |this| binding defaults to the dynamic  
rule from ES1-3, which is weak.

> That is, users of the interface see the type as being the same as the
> interface, but implementors must use their own type here. The example
> is identical to clone's return type being IClonable, except that
> implementors are required to declare a stronger type.

Good point. I'll defer to Cormac on commenting further.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Self type

[Brendan Eich]

On Aug 14, 2007, at 10:10 AM, liorean wrote:

>> Peter Hall wrote:
>>> type B = {b:Self};
>
> On 14/08/07, Cormac Flanagan <[EMAIL PROTECTED]> wrote:
>> Yes, I think this should be fine.
>
> I'm all for allowing recursive structural types e.g. for use as binary
> trees or linked lists.
>
> type BinTree = {sin:Self, dx:Self, value:*};

We've decided *not* to specify recursive structural types in general.  
The subtype relation is O(exp(n)) for the simpler algorithm [1], and O 
(n^2) for a fairly complex successor algorithm [1]. In the interest  
of simplicity and to minimize costs to small-device implementations,  
we are leaving out recursive structural types of ES4. They could be  
added later; for now, if you need trees and the like, use nominal types.

Dave Herman's analysis is on the wiki, but for some reason I'm  
getting an error trying to access the relevant page [3].

Self-references may be good enough for common "recursive" cases  
(iterator::get, clone, equals, etc.).

/be

[1] http://research.microsoft.com/Users/luca/Papers/SRT.pdf
[2] http://www.cs.ucla.edu/~palsberg/paper/mscs95-kps.pdf
[3] https://wiki.ecmascript.org/ECMA/wiki/doku.php? 
id=discussion:classes_as_structural_types_with_branding

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Self type

[Brendan Eich]

On Aug 14, 2007, at 12:46 PM, Nicolas Cannasse wrote:

> Have you not considered having a two-level type spec ? One for
> compile-time and one for runtime ? If I'm not wrong, Java did that  
> with
> generics.

We do not want a profiled or segmented specification, apart from the  
optional strict mode; we do not want erasure. Since strict mode is  
optional (browsers and small-device implementations will leave it  
out), runtime semantics cannot depend on it.

> The only problem so far is that it seems there is no structural types
> support in AVM2/Tamarin yet, or did I miss it ?

No, it's on the to-do list.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: array slice syntax

[Brendan Eich]

On Aug 16, 2007, at 10:42 AM, Lars T Hansen wrote:

> On 8/16/07, Stefan Gössner <[EMAIL PROTECTED]> wrote:
>> Hello,
>> here are my first questions after following the list quite a while.
>>
>> 1. I really like the array slice syntax [start:end:step] described in
>> http://developer.mozilla.org/es4/proposals/slice_syntax.html
>>
>> The description seems to miss the case, where 'start' is greater  
>> than 'end'.
>>
>> a[5:2]
>>
>> Will
>> (a) 'step' be implicitely set to -1 ?
>> (b) an empty array come as result ?
>> (c) an error occur ?
>
> The description seems to be clear here, the result should be an  
> empty array.

Same as for Python:

 >>> s = [1,2,3]
 >>> s[2:1]
[]

>
>> 2. The descendant operator '..' is mentioned only in the tutorial
>> introduction.
>> http://developer.mozilla.org/es4/spec/ 
>> chapter_1_tutorial_introduction.html
>> I could not find it mentioned elsewhere.
>>
>> Is it also considered to work with array notation as in:
>>
>> y..[0]   // access the first element of all arrays of 'y' and it's
>> descendants.
>
> I don't think so.  The descendant operator is for E4X (ECMAScript for
> XML, ECMA-357) and has not been discussed in other contexts.  E4X is
> not included in ECMAScript 4 at this stage.

We are reserving E4X syntax but not requiring it to be supported.

The .. operator bugs me because it implicitly quotes its right  
operand (as . does), so you could not use it as Perl and other  
languages do for range operator. If it were a dyadic operator that  
did not quote either operand, than it could be overridden by the  
operators proposal (or an operators proposal, at any rate ;-) and  
made to work for range (integer literal or value on left) as well as  
for E4X (XML on left).

Generalizing query, matching, and filtering from E4X to the whole  
language, cleaning up the "un-JavaScript-y" aspects of E4X, making  
use of practical research such as JMatch [1], all will have to wait  
for a future Edition. But we certainly can discuss ideas here. Please  
feel free to do so.

/be

[1] http://www.cs.cornell.edu/Projects/jmatch/
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Self type

[Brendan Eich]

On Aug 16, 2007, at 11:42 AM, Dave Herman wrote:

>> Dave Herman's analysis is on the wiki, but for some reason I'm
>> getting an error trying to access the relevant page [3].
>>
>> ...
>>
>> [3] https://wiki.ecmascript.org/ECMA/wiki/doku.php?
>> id=discussion:classes_as_structural_types_with_branding
>
> You've got the URL wrong here; it should be:
>
> http://wiki.ecmascript.org/doku.php? 
> id=discussion:classes_as_structural_types_with_branding

Whoops, you're right -- mistranscription of the internal dokuwiki URL  
to the new ecmascript.org one, sorry.

> Is there a broken link somewhere?

No, but I'm getting permission denied now.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Array and Object Literal Types

[Brendan Eich]

On Aug 17, 2007, at 2:47 PM, Garrett Smith wrote:

> It would be nice to have Array literal syntax declare it's ArrayType
> before the declaration of the array.
>
> For example:
>
> 1. var x : Array = [ "foo", "bar", document.title,  
> getAnotherString() ];

Array is not a parameterized type. If it were, the syntax would be  
Array..

Array must be backward compatible, so if it were changed to be  
parameterized by element type, then it would have to default to  
Array.<*> when used without a parameter list. But we don't have  
default type parameters, and anyway a type-parametric Array reference  
without the actual type param list would be ambiguous: should it mean  
Array.<*> by default, or Array, with instantiation using an actual  
type param happening later: let A = Array; type TA = A. ?

So there's no good way to overload Array as you want.

Also, Array is closer to Object than to any homogenous tuple or  
vector type. Hence the separate

http://wiki.ecmascript.org/doku.php?id=proposals:arrays
http://wiki.ecmascript.org/doku.php?id=proposals:vector

proposals.

> 2. var x = [ "foo", "bar", document.title, getAnotherString() ] :  
> String;
>
> example 1 is more clear to read because in a long array, you'd see
> right away what type of Array it is.

Please see the above proposals and the prior proposals:

http://wiki.ecmascript.org/doku.php?id=spec:type_system
http://wiki.ecmascript.org/doku.php?id=spec:type_relations

> Is the former syntax (or some variant thereof) going to be available?

No, as explained above. But what you might want is:

let x : [string] = ["foo", "bar", document.title, getAnotherString()];

Notes:
* let trumps var in any hand ;-)
* string is the type of "foo", String is the dynamic class for  
wrappers, as in ES1-3 that shares its .prototype with string  
instances as well as String instances, via the usual prototype-based  
delegation. Prefer string in general.
* [string] is a type expression denoted a structural array type.

> What about for Objects?

See structural object types.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: const VS static final class variable ?

[Brendan Eich]

On Aug 17, 2007, at 1:10 PM, Garrett Smith wrote:

> what is the difference between x1 and x2?
>
> class A {
>const x1;
>static final x2;

You need a var before x2. Also you can't add final except before  
classes and methods (the reference implementation currently parses  
'class A { static final var x; }' but that's a bug).

Are you thinking of Java, or some other language here? If this is  
based on an ES4 example or spec, can you cite the URL?

The obvious difference, ignoring the intended illegality of static  
final var x2, is that x2 is static, so per class, not per instance.

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Are Static Members Inherited?

[Brendan Eich]

This has come up on this list before; please see the archive:

https://mail.mozilla.org/private/es4-discuss/2007-January/thread.html  
(the "inheriting statics" thread).

Also, what section 9.2.7 do you mean? Could you cite the URL of the  
document containing that section? Thanks,

/be

On Aug 17, 2007, at 2:05 PM, Garrett Smith wrote:

> The example in section 9.2.7 demonstrates static members, including
> those of an ancestor superclass, being accessible through an instance.
>
> Section 9.6.2 clearly states that static methods are not accessible
> through derived class objects (though does not mention anything about
> static properties).
>
> Am I to understand that static members (methods and properties) are
> visible through the scope chain of instances of derived classes (as in
> example in 9.2.7)?
>
> 2. Can static methods be abstract? I think that this should be a
> compile-time error (static abstract function).
>
> Garrett
> ___
> Es4-discuss mailing list
> Es4-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: const VS static final class variable ?

[Brendan Eich]

On Aug 17, 2007, at 3:37 PM, Brendan Eich wrote:

> On Aug 17, 2007, at 1:10 PM, Garrett Smith wrote:
>
>> what is the difference between x1 and x2?
>>
>> class A {
>>const x1;
>>static final x2;
>
> You need a var before x2. Also you can't add final except before
> classes and methods (the reference implementation currently parses
> 'class A { static final var x; }' but that's a bug).
>
> Are you thinking of Java, or some other language here? If this is
> based on an ES4 example or spec, can you cite the URL?
>
> The obvious difference, ignoring the intended illegality of static
> final var x2, is that x2 is static, so per class, not per instance.

I should add that const is write-once, so you can have a const x1  
instance field. A constructor could write three different values to  
three different instances' x1 fields. In this case const does not  
mean per-class, as static const does, or a hypothetical static final  
var might.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: class prototype object vs class instance properties

[Brendan Eich]

On Aug 18, 2007, at 10:13 AM, Garrett wrote:

> liorean wrote:
>>> What would be the benefit of a class having a prototype over  
>>> 9instance
>>> properties/methods?
>>
>> Prototype properties can be shadowed by instance properties without
>> being changed, prototype properties are fallbacks if the instance
>> property does not exist, and prototype properties are not part of the
>> actual instance, so can be used as memory footprint reduction if one
>> has lots of instances that don't need separate values for that
>> instance property.
>> -- 
>
> That's pretty much how es3 works, then.

In fact the reference implementation at http://ecmascript.org/ uses  
ES4 class definitions to create the built-in classes from ES1-3  
(Object, Date, etc.). A few fine points:

In |dynamic class Object {...}|, the |dynamic| keyword is required if  
you want the class's instances, not just its prototype, to allow ad- 
hoc properties to be set on them. So indeed, |Object| is a dynamic  
class in the reference implementation.

In |class C { var x; }; c = new C; c.x = 42| and |dynamic class D  
{ prototype var x; }; d = new D; d.x = 42| both c and d wind up with  
an x property having value 42. But c.x is a "fixture" -- it can't be  
deleted, and if it has a type annotation, that type constraint can't  
be altered. Whereas d.x is just an ad-hoc property on a dynamic  
class's instance, which happens to shadow prototype var x, but has no  
type relation to that prototype property.

A function definition inside a class C's body |class C { function m 
():void {...} ...}| creates a method fixture named m, which has a  
function structural type |function (this:C):void| and which can't be  
deleted or overwritten.

So classes, fields (var in class), and methods (function in class)  
respectively provide objects with private members where the instances  
cannot be extended, properties that can't be deleted or have their  
type annotations violated, and receiver-based method dispatch (again  
with existence and type guarantees). These can be emulated in ES3 in  
several ways, at some cost in clarity and runtime efficiency.

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: class prototype object vs class instance properties

[Brendan Eich]

On Aug 18, 2007, at 1:51 PM, Garrett Smith wrote:

> But these methods are also bound, right?

Yes, good point -- I left out that further detail. |this| always  
refers in a method to the instance from which the method was called  
or extracted.

> In current coding conventions, many programmers (including myself)
> like to have the constructor's prototype assigment in one place with
> an object literal.

Yeah, I like and use that convention too.

> This "object literal"styleis not congruent to the prototype being a
> special instance (as in ES3 and 4 built-ins, with Date.prototype
> having value NaN, et c) . The above code style is clear and easy to
> read. You have the constructor, then the prototype.
>
> It would be nice to have a prototype block, like:
>
> class A {
>
>   init  : void =  function init()
>   prototype {
>
>   }

This is something proposed ages ago by Waldemar Horwat (then at  
Netscape) for ES4 -- any time you have

   prototype function m1(...) {...}
   prototype function m2(...) {...}
   prototype function m3(...) {...}

in some ES4 drafts waldemar wrote, you could instead say

   prototype {
 function m1(...) {...}
 function m2(...) {...}
 function m3(...) {...}
   }

Waldemar's proposal allowed this for any kind of "attribute"  
qualifying a definition, including a namespace IIRC.

I'll bring this up at the next meeting, since you are quite right  
that the current builtins in the reference implementation are chatty.

> I am not sure if the with(prototype) { ... } would be suitable for
> that approach. I think with statements should not be encouraged.

Right, |with| is not suitable here -- it won't change the scope in  
which functions and vars are bound in a class any more than it would  
elsewhere (as it does not in ES1-3). Also, it is being deprecated  
(there's a reformed with that can be used if you're retrofitting, or  
if you like with and want to use it without scope ambiguity).

> I'm also confused on the syntax for function return type.
>
> ES4:
>>> class P { f:Void=  function  f()  {print('fff');}}
> [function Function]
>>> new P().f()
> [stack] []
> **ERROR** EvalError: uncaught exception: ReferenceError: unresolved
> object reference {multiname: [ns public '']::f } (near
> builtins/Error.es:83.47-83.47)

You didn't define a method f in class P. Look:

 >> class P { f:Void=  function  f()  {print('fff');}}
[function Function]
 >> Void
[function Function]
 >> Void()
fff

the f: is a section label, like private: or public:. The Void name is  
unbound and on the left-hand side of assignment (=) in class P's  
initialization code, so that's an assignment expression-statement  
executed once when the class is processed. Per the usual rules, the  
assignment binds a global property named 'Void'.

I don't know where you saw an example that looked anything like that.  
In the mail I wrote, to which you are replying here, I showed a void  
method:

class C { function m():void {...} ...}

The return type annotation, which is optional, goes after the  
function formal parameter list, and starts with : as for all type  
annotations. The use of |void| here shows a special case: 'void' is  
not a type name, it means instead that the function cannot contain  
'return expr;' statements, only 'return;' statements and falling-off- 
the-end-without-return. There is no 'Void' type in ES4. The type of  
the undefined value is a type named undefined (available only in type  
expression contexts), same as for null/null.

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Comments to the JSON related proposals

[Brendan Eich]

Hey Kris, Simon; a few comments:

On Aug 19, 2007, at 9:45 PM, Kris Zyp wrote:

>> where a filter might be used which have quite different needs: in  
>> the case
>> of temporary/internal keys scattered in an object, it might be  
>> easier to
>> just specify those keys and be done with it
> Specifying temporary/internal keys on serialization is generally a  
> poor
> approach, but rather the temporal natural of keys should be a part  
> of the
> definition of object behavoir/type. I believe ES4 should have a  
> property
> modifier "transient" (like Java), and then the properties would be  
> defined
> as temporary in the class definition

Who said anything about 'class'? :-)

JSON is and remains class-less, serializing Object and Array data  
definitions, whether created by object and array initialisers or not.  
So transient doesn't apply to array, but given the ongoing lack of  
requirement for class-based programming, and the low odds of that  
style taking over for JS apps producing and consuming JSON, the  
question arises: How would ad-hoc transient properties be set or  
initialized in any old object?

> It seems to me that JSON is not even close to attempting to be  
> reversible
> for the general JavaScript objects, but only for simple data  
> structures. The
> list of things that JSON can not serialize in ES3 (and then  
> deserialize to
> original state) includes circular references, multiple references  
> to single
> objects, dates, functions, objects with prototypes, arrays with  
> strings
> keyed properties, and so on. In ES4 the gap grows even wider with  
> typed
> objects and namespaced keys (IMHO the namespaced keyed objects of  
> ES4 almost
> feels to me conceptually incompatible to string keyed objects of  
> JSON).

Superset, not incompatible. Even in ES3 there are types that don't  
exist in JSON, as well as other kinds of structures that can't be  
serialized, as you note. JSON is not going to change much, AFAICT.

The challenge for any language trying to provide safe and usable APIs  
to produce and consume it is what to do when the input to the  
serializer can't be represented. Dropping a namespace qualifier is  
bad because it will lead to local name collisions (Murphy says). In  
general, silently dropping names and types that don't fit in JSON  
seems like deadly silence, not the golden kind.

/be


___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Comments to the JSON related proposals

[Brendan Eich]

On Aug 20, 2007, at 7:57 AM, Kris Zyp wrote:

>> question arises: How would ad-hoc transient properties be set or
>> initialized in any old object?
> With classes being available, why not provide a pathway for  
> developers to
> define transience correctly in proper OO manner that would be  
> serialization
> method agnostic, rather than adding a blacklisted array parameter to
> toJSONString, which IMHO is very poor and shortsighted way of defining
> transient/temporary keys?

Proper OO beliefs aside, you could justify lots of annotations other  
than type annotations for things like serialization, documentation,  
etc. We have a deferred proposal for documentation, for example:  
http://wiki.ecmascript.org/doku.php?id=proposals:documentation

So yeah, one might want both

class Foo {
   transient var bar:
   ...
}

and

let obj = {transient baz: 42, ... };

> I thought that dropping namespace qualifier had already been  
> decided on.

We're not done with this proposal, and anyway we revisit decisions  
when there's good reason.

> Is
> this still in question? I certainly agree that dropping namespaces  
> seems
> dangerous, and when I asked before it was suggested that there  
> could just
> simply be multiple identical keys in a JSON serialization output.  
> Seems a
> little odd to stringify to something that is not even coherent JSON.

I agree.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: 9.6.2 - 'this' or 'super' in a static method

[Brendan Eich]

On Aug 20, 2007, at 2:14 PM, Garrett Smith wrote:

> In ES3, i use this in context of a function instance.
>
> A = function A () {
>
> }
> A.instances = { };
> A.getById = function getById( id ) {
>   return ( this.instances.hasOwnProperty( id ) && this.instances 
> [ id ] ) ||
> ( this.instances[ id ] = new this( id ) );
> };
>
> static this?

Yes, it's natural to expect |this| in a "class static method" to be  
the class object. I've mentioned this to Jeff and we talked about the  
trade-offs with respect to outlawing |this|. The binding of |this| in  
your example does depend on how A.getById is called, and will be  
wrong if the method is extracted and called via another base object.  
But, one could argue that's a bug to fix with real class statics, not  
a reason to think |this| might be considered ambiguous.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: 9.6.2 - 'this' or 'super' in a static method

[Brendan Eich]

Yeah, that's Jeff's position. It certainly is true that this-binding  
is non-trivial because dynamic in ES1-3. In ES4 for any function in a  
class, it's fixed. The current proposal outlaws it in static methods  
(not sure where this is written down, but like Fox Mulder, I want to  
believe), and specifies this-binds-to-object-from-which-method-was- 
extracted-or-called for instance methods.

We could let this alone, and say "use the class name" for static  
methods, for sure. Or we could add "this class". Comments?

/be

On Aug 20, 2007, at 6:15 PM, Neil Mix wrote:

> My experience with mere mortals (e.g. me) is that over time classes
> accumulate methods, and often no one bothers to take time to group
> static methods together in the source.  This makes it easy to
> errantly put "this" inside a static method without realizing the
> implications.  Java's compile-time catch of that problem is nice.
>
> I see the value of referring to the class within a static method
> (other than by using the class name itself).  I also think it may be
> advisable to use an identifier other than "this".  Otherwise it's too
> easy to miss the fact that a method is static.
>
> Another way to state this: most programmers new to JS struggle with
> figuring out what "this" refers to in a given context.  Adding yet
> another situation in which "this" could be this or that seems a bit
> risky.
>
> On Aug 20, 2007, at 4:24 PM, Brendan Eich wrote:
>
>> On Aug 20, 2007, at 2:14 PM, Garrett Smith wrote:
>>
>>> In ES3, i use this in context of a function instance.
>>>
>>> A = function A () {
>>>
>>> }
>>> A.instances = { };
>>> A.getById = function getById( id ) {
>>>   return ( this.instances.hasOwnProperty( id ) && this.instances
>>> [ id ] ) ||
>>> ( this.instances[ id ] = new this( id ) );
>>> };
>>>
>>> static this?
>>
>> Yes, it's natural to expect |this| in a "class static method" to be
>> the class object. I've mentioned this to Jeff and we talked about the
>> trade-offs with respect to outlawing |this|. The binding of |this| in
>> your example does depend on how A.getById is called, and will be
>> wrong if the method is extracted and called via another base object.
>> But, one could argue that's a bug to fix with real class statics, not
>> a reason to think |this| might be considered ambiguous.
>>
>> /be
>>
>> ___
>> Es4-discuss mailing list
>> Es4-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es4-discuss
>
> ___
> Es4-discuss mailing list
> Es4-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Comments to the JSON related proposals

[Brendan Eich]

On Aug 21, 2007, at 1:24 AM, zwetan wrote:

> +1 for being able to set the attributes
>
> but I think we should not add a TRANSIENT attributes for ES3,
> DONTENUM should be enought and backward compatible

See http://wiki.ecmascript.org/doku.php?id=proposals:enumerability

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Comments to the JSON related proposals

[Brendan Eich]

On Aug 21, 2007, at 1:36 PM, zwetan wrote:

> On 8/21/07, Brendan Eich <[EMAIL PROTECTED]> wrote:
>> On Aug 21, 2007, at 1:24 AM, zwetan wrote:
>>
>>> +1 for being able to set the attributes
>>>
>>> but I think we should not add a TRANSIENT attributes for ES3,
>>> DONTENUM should be enought and backward compatible
>>
>> See http://wiki.ecmascript.org/doku.php?id=proposals:enumerability
>>
>
> ok, but is it still at the proposal stage or does DontEnum() and  
> DontDelete()
> are accepted :) ?

Not likely. We aren't adding more properties if we can help it.  
DontDelete is dangerous -- it is necessary for integrity properties  
on which security depends, unlike DontEnum.

> also to be "complete" a ReadOnly() could also be usefull,

Also bad news for integrity.

> I mean also in the context of JSON serialization/deserialization
> to protect some properties to be overriden by the parsing of a JSON  
> string

JSON is not being extended, but we have

let obj = {const FOO: 42, ...};

so you can make read-only properties in object initialisers.

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Comments to the JSON related proposals

[Brendan Eich]

We must keep DontDelete and ReadOnly invariant. See my reply to zwetan.

/be

On Aug 21, 2007, at 2:16 PM, Kris Zyp wrote:

>>> but I think we should not add a TRANSIENT attributes for ES3,
>>> DONTENUM should be enought and backward compatible
>>
>> See http://wiki.ecmascript.org/doku.php?id=proposals:enumerability
> If we added the ability to set attributes, the propertyIsEnumerable  
> extra
> parameter proposal would be unnecessary (albiet convenient). Also,  
> IMHO,
> transient and dontenum are different concepts. They both affect  
> enumeration,
> but one in the context of introspection and one in the context of
> serialization.
> Kris
>
> ___
> Es4-discuss mailing list
> Es4-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Comments to the JSON related proposals

[Brendan Eich]

On Aug 22, 2007, at 12:20 PM, Kris Zyp wrote:
> Always invariant? What's wrong with being able to turn on ReadOnly,  
> but not
> turn it off? Seems I recall seeing code in Rhino that already  
> behaved that
> way...
> Kris

Turning off is the problem for integrity, but turning on is a pain  
for any number of implementation and usability reasons. What's wrong  
with initialiser and declarative support for on-from-the-start?

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Question about spec

[Brendan Eich]

On Aug 22, 2007, at 2:17 PM, rasmus ekman wrote:


Just an arbitrary newbie question...
I note that the updated UnaryExpression BNF
codifies part of the behaviour of ES-262 implementations:

UnaryExpression ->
PostfixExpression
| delete PostfixExpression
| void UnaryExpression
| typeof UnaryExpression
| ++ PostfixExpression
| -- PostfixExpression
| + UnaryExpression
| - UnaryExpression
(etc)

So a is ruled out at syntax level, and -++a is legal while ++-a  
isn't.

This matches (part of) behaviour of current implementations.

But is ++a++ going to become legal?


Never, provided ++a cannot result in a magic native object of some  
kind (which could be an lvalue). See ECMA-262 Edition 3, Chapter 16:


An implementation may treat any instance of the following kinds of  
runtime errors as a syntax error and therefore report it early:

• Improper uses of return, break, and continue.
• Using the eval property other than via a direct call.
• Errors in regular expression literals.
• Attempts to call PutValue on a value that is not a reference (for  
example, executing the assignment statement 3=4).
An implementation shall not report other kinds of runtime errors  
early even if the compiler can prove that a construct cannot execute  
without error under any circumstances. An implementation may issue an  
early warning in such a case, but it should not report the error  
until the relevant construct is actually executed.



In IE ++a++ etc are reported as runtime errors.


It's allowed to, per the above chapter and verse.


Seamonkey


(SpiderMonkey)


code goes directly to MemberExpression after matching ++/--,
is this the intention? If so, why not in spec?


The spec intentionally under-specifies to allow for different  
implementation strategies.


IMHO, the ES1-3 specs do this too much, and we are trying to improve  
the situation for ES4. Note however that C, Scheme, and lots of other  
languages under-specify even more aggressively. JS is different,  
because interoperation across browsers and other "JS engines" is more  
the rule than for other languages, which may cluster in source form  
in silos where only one compiler is used. For fun, read through  
Dawson Engler's http://www.stanford.edu/~engler/spin05-coverity.pdf  
some time.


/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Function.prototype.curryCall()

[Brendan Eich]

That's partial application, not currying. No one has proposed its  
standardization; lots of Ajax libraries implement it much as you show  
below. The ones I've looked at play their own custom variations on a  
theme, so wouldn't all be subsumed by a standard.

/be

On Aug 28, 2007, at 2:20 PM, Peter Michaux wrote:

> Hi,
>
> Has JavaScript support for function currying been proposed? Maybe
> there is already something like this planned?
>
>
> Function.prototype.curryCall = function(scope) {
>   var args = [];
>   for (var i=1; i   args.push(arguments[i]);
>   }
>   var f = this;
>   return function() {
>   for (var i=0; i  args.push(arguments[i]);
>}
>   return f.apply(scope, args);
>   }
> }
>
>
> //
> // Example use
>
> function foo(a, b, c, d) {
>alert(this.name + a + b + c + d);
> }
>
> var bert = {name:'Bert'};
>
> var curriedFoo = foo.curryCall(bert, 1, 2);
>
> curriedFoo(3, 4); // alert says "Bert1234"
>
>
>
>
> Currying is handy when attaching event handlers in a for loop since
> for loops don't introduce a new scope with each iteration.
>
> Suppose we want to attach a click handler to each item in an HTML
> list. The handler prints the position of the item in the list and also
> the innerHTML of the item. One way we could write this handler...
>
> function handler(i) {
>   alert('item ' + i + ': ' + this.innerHTML);
> }
>
> var items = document.getElementById('myList').getElementsByTagName 
> ('li');
>
> // three ways to attach the handlers
>
> //
> // OPTION 1:  inline currying (what a mess)
>
> for (var i=0; i   var item = items[i];
>   item.addEventListener('click', (function(item, i) {
>  return function(){
>  return handler.call(item, i);
> }
>   })(item, i), false);
> }
>
>
> //--
> // OPTION 2: extracted currying (a little nicer)
>
> function curryHandler(item, i) {
> return function() {
>   return handler.call(item, i);
> };
> }
>
> for (var i=0; i   var item = items[i];
>   item.addEventListener('click', curryHandler(item, i), false);
> }
>
>
> //
> // OPTION 3: with Function.prototype.curryCall (succinct!)
>
> for (var i=0; i   var item = items[i];
>   item.addEventListener('click', handler.curryCall(item, i), false);
> }
>
> The event object will be passed as the second argument to the  
> handler function.
>
> There is precedence for other developers wanting this functionality. I
> believe Prototype's Function.prototype.bind() may be the same thing as
> the Function.prototype.curryCall() that I've written. The Prototype
> Function.prototype.bindEventListener() will pass the event object as
> the first argument to the curried function.
>
> Any thoughts on the utility of currying as part of JavaScript?
>
> Peter
> ___
> Es4-discuss mailing list
> Es4-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: some errata in PDF

[Brendan Eich]

On Sep 3, 2007, at 3:00 AM, Lars T Hansen wrote:

> On 8/26/07, Garrett Smith <[EMAIL PROTECTED]> wrote:
>> Back to "caller"...
>> "caller" is on the prototype in Mozilla.

Not lately:

js> function f(){ return f.hasOwnProperty('caller')}
js> f()

This is a SpiderMonkey REPL based on code going into Firefox 3.

> Retch.  Granted the content distribution and security models of the
> web make this kind of attack much less potent, and some of the
> introspection functionality proposed for ES4 may have similar issues
> (not clear to me yet), but "caller" has a lot of problems.

That's why it was never standardized. It was a bogo-reflection from  
Netscape 2. That it's not in JScript says to me that other  
implementations can drop it. Mozilla 2 won't support it, FYI.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: some errata in PDF

[Brendan Eich]

On Sep 3, 2007, at 7:10 PM, Brendan Eich wrote:

> On Sep 3, 2007, at 3:00 AM, Lars T Hansen wrote:
>
>> On 8/26/07, Garrett Smith <[EMAIL PROTECTED]> wrote:
>>> Back to "caller"...
>>> "caller" is on the prototype in Mozilla.
>
> Not lately:
>
> js> function f(){ return f.hasOwnProperty('caller')}
> js> f()

true

(was the line I failed to include in that copy/paste.)

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: URI Proposal

[Brendan Eich]

ES embeddings exist where URIs make no sense, so it's not a good  
candidate for the core standard. But we expect the burgeoning Ajax  
ecosystem to keep on burgeoning (http://www.answers.com/main/ntquery? 
gwp=13&s=burgeon), and make good use of shared library hosting  
arrangements such as those provided by code.google.com and the like.  
This should yield innovation and consolidation, as it has already for  
some JS libraries, and as it did over the years for C (like JS, C  
lacks built-in I/O primitives -- teletypes then or URIs now would not  
fit in the core language).

You could make the same argument I'm making here about JSON and a few  
other standard library proposals. I will not special-plead on their  
behalf. Indeed we've had open issues about the detailed design of the  
"right" JSON API on this list, which linger and nag (at me, at any  
rate).

ECMA would be foolish to try to standardize too much I/O mechanism  
and the like prematurely, but you and others on es4-discuss should  
definitely collaborate (and on this list, for now -- we could use the  
feedback both ways).

/be

On Sep 7, 2007, at 2:29 PM, Garrett Smith wrote:

> I've decided to propose a URI class to deal with the handling of URIs
> that is so prevalent in Ajax apps and also in Flash and to a lesser
> extent, Adobe Reader.
>
> I propose this idea here because noticed that there are other places
> besides the web that can use it (Flash, Reader). A URI class could be
> implemented in ES to cover all these needs.
>
> I have a proposal page at http://www.dhtmlkitchen.com/rec/URI.html
>
> I won't copy paste the entire thing here. It prints on 3 pages if you
> set margin to 0 and scale to 70%.
>
> Is this the appropriate way to make a proposal?
>
> Garrett
>
> -- 
> Programming is a collaborative art.
> ___
> Es4-discuss mailing list
> Es4-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: isPropertyEnumerable is going to stay broken?

[Brendan Eich]

On Sep 8, 2007, at 10:06 PM, Garrett Smith wrote:

> https://bugzilla.mozilla.org/show_bug.cgi?id=57048
>
> In this bug, dated 2000, Brendan and David agreed that
> isPropertyEnumerable should check the prototype chain.

That was a long time ago, and while David Flanagan carries a lot of  
weight with many folks, he was not on ECMA TC39 TG1, and no one on  
the group changed the spec.

A lot of water under the bridge since then.

> It should not backwards compatibility,

Famous last words. :-)

We try to spider the web (Alexa top 1000 and the like) looking for  
counterexamples to such claims, and if we fail to find any, or  
better, we find instances of confusion where the incompatible fix is  
assumed (i.e., the JS author thought the spec worked the way we want  
to change it to work), then we have some confidence, but not much  
more, in favor of making an incompatible change. In general. In this  
case, no one has done such a scan. I'll see if I can get one started.

> but such functionality in the
> language seems necessary. How to check enumerable attribute, including
> the prototype chain?

Either reflect the __proto__ (read-only, please) property as some  
implementations do, or hardcode the prototype structure and code your  
propertyIsEnumerable tests accordingly.

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: isPropertyEnumerable is going to stay broken?

[Brendan Eich]

On Sep 10, 2007, at 1:21 PM, liorean wrote:

> On 10/09/2007, Brendan Eich <[EMAIL PROTECTED]> wrote:
>> Either reflect the __proto__ (read-only, please) property as some
>> implementations do, or hardcode the prototype structure and code your
>> propertyIsEnumerable tests accordingly.
>
> Would it be possible to add an optional boolean parameter for
> searching including the whole prototype chain, so that we get a
> mechanism to do this that doesn't depend on implementation specifics

The alternative above would standardize read-only __proto__, which  
would make that property no longer implementation-specific. But of  
course we have no proposal to do that.

> or code structure?

Adding another optional argument to propertyIsEnumerable is ugly,  
since ES4 has a long-standing proposal to add an optional boolean  
parameter for changing enumerability. Two trailing optional  
parameters, without named parameters, poses usability (both when  
writing code and reading it) hazards. Over-engineering with one  
optional object parameter, supporting "keyword" properties, seems bad  
too -- we want propertyIsEnumerable to remain simple, with few  
arguments in toto.

Is the ES3 behavior a true usability problem in the field, or more of  
a discordant spec glitch that we can live with?

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: isPropertyEnumerable is going to stay broken?

[Brendan Eich]

On Sep 10, 2007, at 2:21 PM, Garrett Smith wrote:

> And my point was that it appears to duplicate functionality of
> hasOwnProperty in a differently named method.

The two functions are different:

js> var Op = Object.prototype;
js> Op.foo = 42;
42
js> print(Op.hasOwnProperty('foo'), Op.propertyIsEnumerable('foo'));
true true
js> print(Op.hasOwnProperty('toString'), Op.propertyIsEnumerable 
('toString'));
true false

> The fact that the method
> was called propertyIsEnumerable instead of isPropertyEnumerable is not
> great, but the way propertyIsEnumerable is designed is confusing to
> developers.

I've never heard that complaint directly, or in a  
bugzilla.mozilla.org report. Can you cite complaints anywhere on the  
web? I believe you, but it would be good to have evidence.

> propertyIsEnumerable and hasOwnProperty are interchangeable (in
> conforming hosts, not JScript)

This statement is false.

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: isPropertyEnumerable is going to stay broken?

[Brendan Eich]

On Sep 10, 2007, at 2:41 PM, Neil Mix wrote:

> I think this is what Garrett is referring to:
>
> js> function f() {}
> js> f.prototype.foo = "blah";
> blah
> js> var x = new f();
> js> print(x.propertyIsEnumerable("foo"));
> false
> js> for (var n in x) print(n);
> foo
>
> And I have to agree with him, the method is confusing.

Sure, but that ship sailed (https://bugzilla.mozilla.org/show_bug.cgi? 
id=57048#c4).

> Based on its
> name, I'd expect it to return true if the property can be enumerated
> via for-in loop on the given object, regardless of where the property
> exists in the prototype chain.

My question remains: is this an incompatible change that will help  
more than it hurts, and otherwise be worth making?

Even with the change, hasOwnProperty and propertyIsEnumerable are  
different, but from Garrett's latest mail it's clear that we agree  
they're functionally the same for most user-defined properties in  
their directly-owning objects.

Enumerability is a weak concept. I wish I'd left it out back in 1995,  
when I was over-minimizing elsewhere.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: __proto__

[Brendan Eich]

On Sep 11, 2007, at 1:47 PM, Kris Zyp wrote:

> __proto__ breaks abstraction boundaries in the language -- it's just
>
> Hiding for the sake abstraction is more valuable than introspective  
> visibility? I disagree, at least with JavaScript, IMHO JS's  
> introspective nature is one of it's greatest strengths. Is there a  
> precedence for this in other languages? Java is big on abstractions  
> but inheritance is still introspectable (I realize that is not  
> completely the same). And I believe that Self, the closest  
> relative, makes the proto available throught .parent* property (I  
> could be wrong about that).

Self has *-suffixed slots that constitute multiple prototypes per  
object. Yeah, JS is reflection-happy, or was. Some of it was  
distorted due to minimization (no activation reflection, so  
fun.caller) and that wasn't standardized. And ES1 intentionally  
censored activation object reflection, so much so that when closures  
were standardized in ES3, the bug where |this| inside a nested  
function does not match the outer function's |this| when the inner is  
called from the outer inadvertently bit.

Reflection is two-edged. It breaks abstraction, removes some theorems  
for free, and with mutation it can do a lot of damage (sometimes a  
good thing ;-).

A read-only __proto__ is hazardous for those factory closures that  
hide the created object's prototype. Without __proto__, you can't get  
at the prototype, which means you can enforce some integrity  
properties about names not being found rather than being found in the  
proto.

A read-write __proto__ is unthinkable (and in SpiderMonkey, complete  
with cycle detection :-P).

> security threat depends on the details of the environment: whether
>
> Hasn't that security threat been evaluated by the years that this  
> property has already been available?

It has, and while __proto__ has been used in some Mozilla PoCs over  
the years, it wasn't that big a deal. It was never exploited in the  
wild that we know of. But it added attack surface and it exacted a  
toll. I am not proposing it for ES4.

/be


___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Regex: How should backreferences contained in the capturing match they reference to work?

[Brendan Eich]

I am not looking to make trouble here, believe me, but I want to  
point out two things that could help David's case:

1. JS regexps were modeled by me (to lwall's horror ;-) on Perl  
regexen. Here's what perl (5.8.8) does:

$ perl
"aaab" =~ /(a\1)+|b/;
print "$& ($1)\n";
b ()

It's no surprise JavaScriptCore agrees, since it is based on PCRE.  
Tamarin is too -- do you know what it does?

2. IE JScript does not agree with any of Perl/JavaScriptCore or ES3  
and conformant implementations. That does not mean it should prevail  
for this edge case. But it does suggest we could change to match  
Perl, and match David's two-person (three counting him; perhaps four  
if I count ;-) developer sample.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: catch-if syntax?

[Brendan Eich]

On Sep 13, 2007, at 7:23 PM, Dominic Cooney wrote:

> I notice that the normative grammar* doesn't mention SeaMonkey's catch
> (identifier if expr) syntax for filtering exceptions. Is that
> deliberate?

Yes, that was a SpiderMonkey (not SeaMonkey, n.b.; it may also be  
supported in Rhino) extension rejected during the ES3 era and not re- 
submitted since.

ES4 does have type-annotated catch variables, which match based on  
first "is" type relation, IIRC.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Regex: How should backreferences contained in the capturing match they reference to work?

[Brendan Eich]

On Sep 14, 2007, at 12:42 PM, liorean wrote:

> On 14/09/2007, liorean <[EMAIL PROTECTED]> wrote:
>> Maybe you don't. But almost all regex implementations that implement
>> capturing submatches that are specifically implementing the ES3
>> algorithm agree with me.
>
> s/that are specifically/that are not specifically/

"Almost all" excludes IE JScript, right? Those implementations are  
JavaScriptCore, based on PCRE, and what else?

Again, it's the Perl connection.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: 13.2.2 [[Construct]], constructor, and [[Class]] (was __proto__)

[Brendan Eich]

On Sep 23, 2007, at 8:59 AM, liorean wrote:

>> 1. The constructor property should be on the object instance  
>> *created*
>> by the function.
>
> That argument I agree with. It should be on the instance and not  
> the prototype.

The reason for the original prototype-owned constructor was to afford  
a back-pointer from prototype to constructor function without  
imposing a per-instance property (which could be optimized to be  
shared where possible, overridden where desired -- but at some cost  
in implementation complexity).

I'm not convinced it's worth changing this for ES4. Anyway it is very  
late to have a new proposal -- we are finalizing proposals next week  
at the face-to-face meeting.

> On 23/09/2007, Garrett Smith <[EMAIL PROTECTED]> wrote:
>> 2. (new function(){}).constructor should be Function.
>
> I agree. And in ES3 it is, unless the function either:

No:

js> (new function(){}).constructor
function () {
}
js> function C(){}
js> new C().constructor
function C() {
}

in no case is the value of (new function(){}).constructor Function.

> - Returns another object than that it was passed from [[Construct]]
> - Creates a constructor property on the this object that is not a  
> function
> - Has it's prototype overwritten

Good points.

> But for ES3 and real web compatibility, I don't think changing the
> algorithm to not allow ordinary ES3 functions used as constructors to
> return objects other than the one set up by [[Construct]] will work.

Right, this will break the web. Tucker can weigh in on the  
workarounds OpenLaszlo needed to cope with the instance of this bug  
in Flash (AS2, and I think AS3 still, do not let a function return a  
different object from the one passed in as this when called via new).

>> ES4 ref impl seems a bit off:
>>
 (new function F(){}).constructor
>> [function Function]

This is on file: http://bugs.ecmascript.org/ticket/64

 new Date(9e9).constructor
>> [class Class]

I don't see this one on file -- someone please file it! Thanks.

 1['constructor']
>> [class Class]
>
> Seems a bit broken, yes...

This one may be covered by other tickets but filing it won't hurt.

>> It appears that es4 ref impl has the correct result for instancof  
>> on primitives
>>
>> All are true in ES4 and false in ES3:
>> true instanceof Boolean
>> "oo" instanceof String
>> 2 instanceof Number
>> null instanceof Object
>> NaN instanceof Number
>> Number.Infinity instanceof Number
>>
>> I think the change is correct. if typeof b == "boolean", b instanceof
>> boolean seems like it must be true.
>
> A bugfix, IIRC.

Incompatbile enough that we are not taking the chance -- we are  
changing this to match ES1-3, and to avoid boolean <: Boolean etc.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: 13.2.2 [[Construct]], constructor, and [[Class]] (was __proto__)

[Brendan Eich]

On Sep 23, 2007, at 12:22 PM, Garrett Smith wrote:

>>> in no case is the value of (new function(){}).constructor Function.
>>
> It shouldn't be, but it is in OSX Ref Impl. (I did not build this).
>
> js> (new function(){}).constructor
> [function Function]

No, that's just http://bugs.ecmascript.org/ticket/64 -- proof:

 >> (new function(){}).constructor
[function Function]
 >> (new function(){}).constructor === Function
false
 >> f = function(){}
[function Function]
 >> (new f).constructor === f
true
 >>

With Function.prototype.toString buggy, you need to test identity of  
function objects.

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: New Feature to JS 1.7

[Brendan Eich]

JS1.7 shipped in Firefox 2 and it is "done". This list is for  
discussion of ECMA-262 Edition 4 (ECMAScript 4, es4) features and  
design decisions. See http://www.ecmascript.org/.


/be

On Sep 24, 2007, at 12:18 AM, <[EMAIL PROTECTED]>  
<[EMAIL PROTECTED]> wrote:



Hello
Where can I post request for new feature to JavaScript 1.7?
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss


___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: New Feature to JS 1.7

[Brendan Eich]

On Sep 24, 2007, at 10:51 AM, Garrett Smith wrote:

> http://wiki.ecmascript.org/doku.php?id=proposals:maintenance_of_es3
>
> The docs for ES3 are gonna be updated?

No commitment from the group yet to do this.

> Including some changes to the spec?

Again no commitment yet from TG1 to pursue this.

I personally believe that the unsound, untestable/non-executable ES3  
spec is a rathole we should avoid. The errata (which are not complete  
by a long shot) that we have hosted at http://www.mozilla.org/js/ 
language/E262-3-errata.html would have to be incorporated, again with  
high risk of bugs and no way to test. I think we are much better off  
working on the ES4 refimpl and the spec derived in part from it.

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Spec page on Wiki not public?

[Brendan Eich]

On Oct 2, 2007, at 4:11 PM, Chris Double wrote:

> I notice the Spec page on the publically accessible wiki comes up with
> "Sorry, you don't have enough rights to continue. Perhaps you forgot
> to login?". Is it possible for this to be public? Page reference is:
>
> http://wiki.ecmascript.org/doku.php?id=spec:spec

This will return with fresh and readable spec materials soon (order  
of weeks), but the old stuff there was just misleading people. Sorry  
for the lack of announcement -- the fact that you were looking means  
we probably did spare you some confusion ;-).

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: New Feature to JS 1.7

[Brendan Eich]

On Oct 7, 2007, at 11:41 PM, Garrett Smith wrote:

>> I personally believe that the unsound, untestable/non-executable ES3
>> spec is a rathole we should avoid. The errata (which are not complete
>> by a long shot) that we have hosted at http://www.mozilla.org/js/
>> language/E262-3-errata.html would have to be incorporated, again with
>> high risk of bugs and no way to test. I think we are much better off
>> working on the ES4 refimpl and the spec derived in part from it.
>>
> That is disappointing to hear.

Why? Which particular word in "unsound", "untestable" and "rathole"  
was wrong, so that you'd be disappointed we didn't charge down that  
tunnel?

> I sent an email to [EMAIL PROTECTED], as it is listed on the front of
> the manual, but did not get a reply.

That mail made it to my attention. The problem besides the lack of  
soundness and testability is that editing minor corrections can be  
done, but creates a difference between the Ecma spec and the ISO  
version of it. Editing non-trivial fixes is not well-supported by  
Ecma process or JTC-1 Fast-track to ISO.

The fix is to do a new Edition, but that's not going to happen just  
to fix a few (or even a lot of) errata. It has been over eight years  
since Edition 3, and the JS authors deserve better than a typo fix or  
three. Our work on Edition 4 is all but specified. Meaning, we're  
about ten months from really all but done with the spec -- spec- 
writing is hard work, but at least this time there will be a testable  
reference implementation provided along with the spec, and bug-fixed  
over time.

Modern standards are not holy writ, and as you note not bug-free.  
They should move toward continual refinement and release, as software  
has (Windows Update, Apple Software Update, etc.). The Ecma process  
is not nearly that continual. The Scheme community wants to move  
toward a more frequent update of their spec (R6RS, R6.1RS, etc.). I'm  
working with Ecma folks to explore a way forward along those lines,  
but it won't happen quickly. The best plan now is to get back to an  
every-two-years release footing, based on ES4.

> If the documentation were amended, understanding would most likely  
> improve.

Maybe, but there're lots of JS books on shelves and people cope  
without delving into the corners of the spec that contain errata. We  
get very few complaints -- yours is one of a few cases where someone  
bothered to mail Ecma.

> BTW, I'm having trouble viewing ecmascript.org now.

Works for me at the moment.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Logical Assignment Operators

[Brendan Eich]

On Oct 9, 2007, at 6:33 PM, Brad Fults wrote:

> Hi,
>
> As far as I can tell [1] there have never been logical assignment
> operators (AND, OR) in ES and I can't access the spec on the wiki [2]
> anymore, so I don't know if they're in the spec. I don't see anything
> in the proposals section, so here's a proposal.

Try the reference implementation when in doubt:

$ make repl
perl bin/repl-with-readline.pl
 >> a = 1
1
 >> b = 0
0
 >> a &&= b
0
 >> a
0
 >> b = "great!"
great!
 >> a ||= b
great!
 >> a
great!

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Type Checking?

[Brendan Eich]

On Oct 10, 2007, at 3:53 PM, Garrett Smith wrote:

> Typechecking is a problem.
>
> typeof is limited and allows host objects to return anything. The
> problem is that some host objects return "function", for example, a
> NodeList in Safari. This is perfectly legal, according to the spec.

See http://bugs.ecmascript.org/ticket/153 -- for a general, universal  
is-it-callable test, you would write

   if (it is Callable) ...

> How is type checking addressed in ES4?

The |is| operator tests universal or Platonic type, which involves  
shared, immutable type descriptors that do not vary across windows or  
frames. So

   if (a is Array) ...

will work no matter where a was constructed.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: convert null values

[Brendan Eich]

On Oct 11, 2007, at 7:21 AM, <[EMAIL PROTECTED]>  
<[EMAIL PROTECTED]> wrote:


When convert null to string it is better to return empty string  
then 'null' string;


var a= null;
var b= '';
b= 'test' + a; //b == 'testnull'; EXPECTED: b == 'test'


This is an incompatible change and there's no point in making it now.

However much better this seems now, that ship sailed 12 years ago in  
Netscape 2 (beta). We do not get any bugs about this at  
bugzilla.mozilla.org, and I've never heard of it as a recurrent cause  
of real-world confusion and bugs, which might justify an incompatbile  
change, if there is no content on the crawlable web that depends on  
null => "null" and only content wishing null => "". So ES4 should  
remain compatible with ES1-3 here.


/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Type Checking?

[Brendan Eich]

On Oct 11, 2007, at 1:36 PM, Garrett Smith wrote:

> On 10/10/07, Brendan Eich <[EMAIL PROTECTED]> wrote:
>> On Oct 10, 2007, at 3:53 PM, Garrett Smith wrote:
>>if (it is Callable) ...
>>
> I wonder how host objects will deal with this.
>
> Will there be a transitive relationship of callable and ()?

For transitivity you need a binary relation. The |is| operator is  
binary and transitive. The () operator is not binary and not in any  
general sense transitive. So I'm not sure what you mean here, but  
moving on:

> If an object accepts arguments, it is callable, and if it is callable,
> it supports ,call(), right?

You mean if (it is Callable) then it.call(thisp, arg1, ..., argN)  
works? No, because (it is Callable) is true for cases where !(it  
instanceof Function). If you want to apply or call a non-function  
callable, use Function.apply(callable, thisp, argArray) or  
Function.call(callable, thisp, arg1, ...argN).

> typeof appendChild; // "object"
> appendChild is Callable; // ???

See the ticket I cited, http://bugs.ecmascript.org/ticket/153, where  
the Callabe structural type is defined as { meta::invoke: * } (or  
possibly { meta::invoke: Function }). That is, if any object  
implements the meta-object hook for invocation, it is callable. As  
shaver notes and ES1-3 put it, this is the [[Call]] meta-method. It  
is exposed in ES4 as meta::invoke. If some future rev of IE (not  
retrofitted with ScreamingMonkey :-/) has a callable DOM method  
appendChild, but (appendChild is Callable) evaluates to false, well,  
that would be a bug.

> In IE, appendChild.call is undefined, yet accepts arguments. It's like
> a host function that's bound, internally, to its node. Its thisArg is
> always the node; execution context is irrelevant. It's an odd duck.

That's not something ES4 will prescribe, but again: use the new-in- 
ES4 static generic Function.call (or Function.apply) if you need to.

> document.all(), document.links(0) are also non-functional, but "do
> something" when you use arguments ().  That something is not [[call]].
> Opera mimicked this odd behavior with document.all and Mozilla did too
> in BackCompat mode.

I don't know what "BackCompat mode" means, but we do reflect  
document.all if a script uses it without object-detecting it, and  
only in such cases (since many well-written scripts fork based on if  
(document.all) ... else ... tests and we want to run the else clause).

This is all not normatively specified by ES4. It's fodder for a  
future WHAT-WG or W3C webapi spec on ES4 DOM binding. But we are  
providing the tools for generalizing callability apart from (it  
instanceof Function), and we are providing static-generic Function. 
{apply,call}. These should be enough.

> Hosts that create such objects create a deceptive and confusing
> interface. It's like "what the heck is this thing?"

I agree, and Gecko's DOM takes pains to reflect methods as instances  
of Function, as far as I know.

I believe this came up on a w3c list in the last year, possibly  
webapi or html-wg. Can someone find the thread?

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Type Checking?

[Brendan Eich]

On Oct 11, 2007, at 8:02 PM, Garrett Smith wrote:

>> If you want to apply or call a non-function
>> callable, use Function.apply(callable, thisp, argArray) or
>> Function.call(callable, thisp, arg1, ...argN).
>>
> So these are equivalent?
>
> aNonFunctionCallableObj()
> Function.call( aNonFunctionCallableObj )

We don't need to go back and forth -- I wrote essentially the same  
thing, but included the optional arguments. The two expressions you  
wrote are equivalent assuming the global object should bind to |this|  
for both to be equivalent.

> If an object is invokable with arguments  (), but not a Callable, it's
> impossible to type check.  IE's call-like operation on with () is not
> [[call]].

Why do you say that? There's no reflection of [[Call]] into the  
language yet, so how can you tell?

(Don't rely on typeof x == "function" meaning x.[[Call]] exists --  
browsers do not follow ES3 here, although we tried in SpiderMonkey  
for years before throwing in the towel.)

> Microsoft often says that it is necessary to retain backwards
> compatibility. I would hope they would

You're barking up the wrong tree here. This is es4-discuss.

> Mozilla has this weird function-like thing, too, (only with
> document.all, which is not used much anymore)

As I keep saying, any reflection of document.all in an ES4 "DOM level  
0 plus IE quirks" binding should indeed make (document.all is  
Callable) => true.

>> I don't know what "BackCompat mode" means, but we do reflect
>> document.all if a script uses it without object-detecting it, and
>> only in such cases (since many well-written scripts fork based on if
>> (document.all) ... else ... tests and we want to run the else  
>> clause).
>>
> document.compatMode
> "CSS1Compat"  -- standards mode
> "BackCompat" - quirks mode
>
> BackCompat supports document.all

No, you're mixing things up. As I wrote, our document.all emulation  
has nothing to do with DOM specs or document.compatMode, and it works  
irrespective of the latter's value.

> Mozilla really made document.all look like IE's weird
> collection-that-can-be-invoked-with-().

Like, yeah -- that was the point!

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Type Checking?

[Brendan Eich]

On Oct 11, 2007, at 10:36 PM, Garrett Smith wrote:

> So that that's out of scope for ES4; it's OK for host objects to have
> custom behavior.

I'm afraid so, but we could say that host objects that are callable  
SHOULD be functions if they appear to be functions otherwise; we  
could say that all callable host objects MUST be compatible with the  
Callable structural type.

> quirksmode -- document.all works
> strict mode  -- no document.all
>
> It is detectable.

Sorry, you are right -- I didn't grok the document.compatMode  
reference, but yeah: based on DOCTYPE we either will resolve  
undetected document.all, or not.

>>> Mozilla really made document.all look like IE's weird
>>> collection-that-can-be-invoked-with-().
>>
>> Like, yeah -- that was the point!
> Was heavily debated and implemented. Water under the bridge, right?

Way under. See

https://bugzilla.mozilla.org/show_bug.cgi?id=248549#c85

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: 'switch' operator improvement

[Brendan Eich]

On Oct 16, 2007, at 8:19 AM, Dave Herman wrote:

> But that's not what you proposed, is it? I understood your proposal to
> mean something more like:
>
> function f(g) {
>  if (let (tmp = g())// case g():
>  (tmp is RegEx ? tmp.match(x) : x == tmp)) 
>  if 
> }
>
> Dave

Right, and that is not only backward incompatible, but user-hostile  
unless you type everything. It's perl-ish magic.

I say use an if-else and call match if that is what you want. EIBTI,  
the Pythonistas say (Explicit Is Better Than Implicit).

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: instanceof Operator

[Brendan Eich]

On Oct 21, 2007, at 11:48 AM, Jeff Dyer wrote:

>> The wrapper classes String, Number, Boolean are similar to the
>> (primitive) values they wrap, but they're not really related to those
>> value types in a type sense, and in ES4 the wrappers are of even less
>> utility than in ES3, I would say.
>>
>
> Right, thanks for the correction. This is an obvious consequence of  
> the
> recent return of primitive wrappers to ES4. 'string' is the new  
> 'String'!

String has its uses, not just embedded in content that requires  
compatibility: string and String inter-convert, String is non-final,  
and the two share a prototype object.

The need for string comes directly from ES1-3, because the primitive  
string type in JS1 was auto-wrapped when you used a string value as  
if it were an object, say to call a method on it. But since a new  
wrapper was created each time (or so it appeared; implementations  
could optimize), the object-ness of the primitive string was  
ephemeral: you couldn't set methods and get them later; any get on  
the wrapper for a property not found on String.prototype or above  
would return undefined.

In ES4, string has catchalls to satisfy this ephemeral wrapper get/ 
set compatibility, but method calls on string instances do not  
require String wrapper creation.

Wrapper creation may or may not be observable in ES3 -- 9.9 says  
"create a new String" but does not say by evaluating |String| in  
order to construct -- but ES4 does not allow any type name to be re- 
bound, so the implementations that chose to construct the wrapper by  
reflecting on the current value of 'String' in the global object,  
thereby allowing someone to replace that binding and spy on wrapper  
construction, no longer need to reflect each time.

The shared prototype object allows for replacement of prototype  
methods, which per ES1-3 and much compatibility-constraining content  
on the web, remain mutably bound in the shared prototype object. Thus  
in ES1-3, if you wrapped String.prototype.charAt with some AOP advice  
function, your code calling "hi".charAt(0) will still run your advice.

Since ("hi instanceof String) was never true, it should not be true  
in the new world. This is one reason string and String are peer  
subtypes of Object, that is, string is not a subtype of String.

Tucker and others have hoped for a way to customize String, and since  
it is non-final and convertible to string, the use-cases that want to  
make custom objects that delegate to String.prototype should work  
too. But it would be good to see some examples.

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: is ES4 getting too bloated?

[Brendan Eich]

I know of two industry-scale implementations under way, in addition  
to Mozilla's Tamarin project, and Michael O'Brien (mbedthis.com), all  
implementing ES4 in the next six to nine months. There's no reason,  
zero, apart from will to do something else, why Microsoft (which has  
enormous resources, in expert people and money) couldn't do likewise.  
Perhaps they yet will -- we don't really know what's coming in IE8 yet.

Give the overview at http://www.ecmascript.org/es4/spec/overview.pdf  
a read and let us know what you think.

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: instanceof Operator

[Brendan Eich]

On Oct 22, 2007, at 4:53 AM, P T Withington wrote:

>> String has its uses, not just embedded in content that requires
>> compatibility: string and String inter-convert, String is non-final,
>> and the two share a prototype object.
>
> I think Dylan would have made String an open subclass of the sealed
> class string: http://www.opendylan.org/books/dpg/db_305.html

We can have dynamic subclasses of non-dynamic classes, but if String  
<: string, then string can't be final, which precludes some  
optimizations and (separate) simplifications. We think these matter  
enough not to make String <: string.

Such a relation would also be "upside down" by comparison to ES1-3,  
where the primitive string type is not an object type, and even if  
you pretended it were, it would not be superior to, or more general  
than, String (in any prototype-based or class-based sense). Exactly  
the opposite is true: String is more general than string.

>> In ES4, string has catchalls to satisfy this ephemeral wrapper get/
>> set compatibility, but method calls on string instances do not
>> require String wrapper creation.
>
> Are you saying for compatibility you have to maintain this 'ephemeral
> wrapper' behavior?

Yes. The use-case is generic programming over string primitives and  
bona-fide ES3 objects: you want to allow "hello" to flow into a  
function farble(x) that gets and/or sets ad-hoc properties on x,  
without exceptions being thrown. Such a function can't count on  
getting what it set, of course (ephemeral wrappers). But it must fail  
soft as it has for going on 12 years.

> My use case is for an annotated string, the result of a sprintf-like
> formatter that remembers the objects associated with each
> representation (so you can inspect a message for more detailed
> information):  http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/
> lfc/debugger/LzMessage.lzs

Looks like it should derive from String and be happy in ES4. I'll  
take a closer look later today.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Units of Measure

[Brendan Eich]

On Oct 26, 2007, at 12:48 PM, Darryl wrote:


I think it'd be interesting and useful to have some
way to have units of measure as part of the structure
of a number.


See http://www.mozilla.org/js/language/old-es4/rationale/units.html  
(and everyone, please help disambiguate by using "program units" when  
talking about the other units, the kind included in ES4 as proposed:  
http://wiki.ecmascript.org/doku.php?id=proposals:program_units ;-).  
Waldemar's write-up there in the old-es4 doc-tree references Dav  
Raggett's Spide (http://www.mozilla.org/js/language/ 
bibliography.html#spice), worth a read too.



It's just an idea but I think it'd be incredibly
useful in the future for designing advanced web applications.


At this point, as the overview says, we are not taking new proposals  
for ES4. Units are tempting to consider for a future Edition, but  
IIRC Waldemar had some unsolved problems in his design. It would be  
good to hear from him, if he remembers the details.


/be___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: "Like" types

[Brendan Eich]

On Oct 26, 2007, at 5:11 PM, James Clark wrote:

Calling the second relationship "like" seems strange to me.  An  
object that stands in the strong relationship to a type is just as  
like the type as an object that stands in the weak relationship.


The canonical term (both in theory and in real programming languages,  
e.g. C#) for the strong relation is "is", not "like".


See the overview generator example for a pretty combination of the two:

function fringe(tree) {
if (tree is like {left:*, right:*}) {
for (let leaf in fringe(tree.left))
yield leaf
for (let leaf in fringe(tree.right))
yield leaf
}
else
yield tree
}

Try it:

let tree = { left: { left: 37, right: 42 }, right: "foo" }
for ( let x in fringe(tree) )
print(x)

It prints 37, 42, and "foo".

In Firefox 2, you can do exactly this example minus the is like test.  
Instead some ad-hoc property-detection is required. See attached.


/be


___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Possibility of standardized sprintf() in ES4?

[Brendan Eich]

On Oct 27, 2007, at 11:06 AM, Dan Scott wrote:

> Just following up on the discussion - since I've seen an  
> announcement that the spec for ES4 is now closed, does this mean  
> that a proposal for an addition of a standardized sprintf / format  
> addition to the String object is off the table until ES5? Or have  
> the Ecma members of the group decided that there is no actual  
> requirement for this functionality?

See http://wiki.ecmascript.org/doku.php? 
id=discussion:string_formatting and also http://wiki.ecmascript.org/ 
doku.php?id=meetings:minutes_feb_24_2006&s=string+formatting, which  
contains:

# String formatting choices:
 * Leave out, defer to the emergent standard library ecology?  
Then lose type system tie-in opportunites.
 * .NET vs. MSCOM vs. Java vs. others leaves no single obvious  
choice of what to imitate.
 * OCaml, other precedents? Roll-our-own function-combinatorial  
typed formatting? Too inconvenient.
 * Ed points out that strings imply localization, more worms.

These considerations suggested to us that we defer this to the  
library ecosystem. But we could have missed an opportunity here.

> Beyond raising this issue on the mailing list and finding some  
> support in principle for the proposal, if not for the actual form  
> of the proposal, I'm not sure what the next step is supposed to be.  
> It does seem like a major functionality gap in the language, to me,  
> but I'm only one small voice.

In your view, is it a gap in the standard library, a gap to fill by  
competing libraries before anything is standardized, or truly a gap  
in the core language? For there to be a gap in the core language, it  
seems to me the proposal must involve static type checking of actual  
arguments against format specifiers. Otherwise, as Lars noted in the  
discussion page, even ES3 has enough reflection to build a  
dynamically type-safe formatter as library code. Successful Ajax  
libraries have built such things.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Brendan Eich]

On Oct 27, 2007, at 8:00 AM, Scott Elcomb wrote:


Hi all,

First off, I'd like to say thanks for all the good questions and
answers from folks on the list.  I haven't been here long, but have
already learned a bunch.  Looking forward to ES4.


Thanks. Here's hoping ES4 as proposed is not quashed by the  
combination of anonymous propaganda campaigns and truly-secret  
maneuverings within the standards body by the pay-to-play members  
(Mozilla is not one; we don't have that access).


What follows below are my opinions, presented bluntly as ever. This  
is long, but evidently necessary and appropriate to es4-discuss. I'll  
blog about the situation soon too.



Anyway, I received this post* this morning in response to a notice I
sent along about the ES4 overview.  I'm not sure what to make of the
story...

Any comments or clarifications?


A link to a slashdot anonymous posting? What's to clarify? :-/

As much as possible, those of us in Ecma TG1 actually working  
productively on ES4 for over two consecutive years have made our work  
and intentions known by means of this list, the http://ecmascript.org  
site, the SML reference implementation, and blog posts and public  
talks I've given.


In opposition, only Doug Crockford has spoken his mind forthrightly  
in the last several months. Good for him (I'll argue with his version  
of the reality elsewhere), but shame on the biggest company involved,  
which has not contributed at all in the open, instead leaving people  
with wrong impressions about its commitment to ES4.


Many people don't know where Microsoft stands, knowing only that it  
contributed over the years to draft ES4 proposals, implemented a  
variant of one such draft specification in JScript.NET, and had one  
of its employees (Rok Yu) contributing to TG1 work, with his name on  
E4X (ECMA-357) as well as ES3 and the 2003 interim ES4 draft report.  
Indeed, up until early this year, the rest of us in TG1 had no clear  
statement of dissent from Microsoft. So, who is not dealing  
forthrightly or openly here?


To be more fair than the opponents of ES4-as-proposed have been, I'll  
add this obvious reassurance: any organization or person can change  
position. Indeed one Microsoft rep confided to me that "we were  
asleep!" about what was going on with Microsoft passively  
participating in TG1 before this year. So let's say there was no  
duplicity, no playing along with the rest of TG1's long-standing  
work, only to reverse suddenly late in the process.


Nevertheless, standards do not require unanimity, and even Microsoft  
loses sometimes. That's life.



* http://article.gmane.org/gmane.org.user-groups.linux.tolug/36420


Cc'ing Walt Dnes.


-- Forwarded message --
From: Walter Dnes <[EMAIL PROTECTED]>
Date: Oct 27, 2007 3:44 AM
Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM
To: [EMAIL PROTECTED]


On Mon, Oct 22, 2007 at 04:04:52PM -0400, Scott Elcomb wrote


An official overview[1] of "Javascript 2.0" was released today.
It will likely be some months (at least) for this version of the
language to show up in web browsers, but it might be a good idea to
get on-board early.


  Not so fast.  See the note on Slashdot Firehose at
http://slashdot.org/firehose.pl?op=view&id=350409

  Since it's not too long, I'll quote it in its entirety...


"At The Ajax Experience conference, it was announced that an
ECMAScript4 white paper had been released. The implication being
that the white paper was the upcoming spec, which is untrue.


That untrue implication comes from the anonymous coward, not from any  
of us involved in TG1 who have worked in the open on ES4. From the  
white paper's introduction:


This overview reflects the position of the majority in Ecma TC39-TG1.  
A minority in TG1 do not agree that the language presented here  
should become ES4. However, Ecma and ISO do not require unanimity to
make standards, and no alternative proposal has been submitted to  
TG1. Therefore the language described in this overview continues to  
be proposed as ES4.


No one reading this overview could confuse it for a specification.  
From the front page of the overview, the first footnote:


This document reflects the understanding of the language as of  
October 2007. TG1 is no longer accepting proposals and has started  
writing the language specification. The ES4 reference implementation  
is undergoing stabilization and is already passing large parts of its  
test suite, and this document describes the final language in most  
respects. That said, TG1 maintains a bug tracking system at http:// 
bugs.ecmascript.org/, and ES4 is subject to further refinement as  
known and new bugs in the design are resolved



Not to
mention this is not an official ECMA site, but a site run by only
some of the members from the ECMAScript4 group.


With permission from Ecma staff.


These facts


The insinuation that someone was passing a self-described overview  
off as a

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Brendan Eich]

On Oct 27, 2007, at 1:53 PM, Dave Herman wrote:

> In fact, Guy Steele gave a famous talk--at OOPSLA, no less--on the  
> importance of language growth.

http://citeseer.ist.psu.edu/steele99growing.html

video: http://video.google.com/videoplay?docid=-8860158196198824415

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Brendan Eich]

On Oct 27, 2007, at 3:38 PM, Scott Elcomb wrote:

> Not sure if you're active on Slashdot or not.  Would you mind if I
> attached your message to the /. thread?  (I won't post it without
> permission, and will mention "with permission" if it's provided.)

You could instead hyperlink to:

https://mail.mozilla.org/pipermail/es4-discuss/2007-October/001309.html

I'm assuming readers who would benefit would know and bother to  
follow a link. (I stopped reading /. long ago, as having my own small  
children to look after involved less chin-wiping and was more  
edifying and entertaining. :-)

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Opaque / abstract types ?

[Brendan Eich]

On Oct 28, 2007, at 5:45 AM, David Teller wrote:

>Hi list,
>
>  After reading the Outline document, I find myself wondering if  
> there's
> a way to provide a type without any method for the user to manually
> create an inhabitant of that type ?

A class with a private constructor. See http://bugs.ecmascript.org/ 
ticket/166.

>  From the Outline, operator "as"

No such operator -- did you mean "cast"?

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Brendan Eich]

On Oct 28, 2007, at 2:16 PM, Robert Sayre wrote:


On 10/28/07, Mark Miller <[EMAIL PROTECTED]> wrote:


But even if you have succeeded at integrating together more good  
ideas

into a coherent language design than have many previous brilliant
language designers, I have another concern: Standards bodies should
not do de-novo design.


JS has evolved since IE6 was released. Many of the "new" features are
already available in ActionScript, Mozilla, Opera, and elsewhere.


Beyond what has happened since MIcrosoft tried to stagnate the web,  
ES4 takes into account solid (and far from novel) research from the  
'90s on generic functions (Dylan, Cecil) and structural types (Modula  
3, others), both of which are variously hard-coded or latent in  
JavaScript: see the existing +, <, and other operators; see also  
object and array duck types used for data definitions, JSON, and the  
like, with ad-hoc shape-testing code enforcing the latent type  
discipline (e.g. MochiKit's Base.isArrayLike).


The most novel aspect of ES4 is the gradual typing support (Siek and  
Taha; Flanagan et al.), but this machinery (like, wrap, the  
compatibility type relation) is almost trivial to prove. You could  
argue that it is not worth including, but putting scare quotes (or  
scare-Latinisms) around it to make it seem bleeding-edge would be bogus.


ES4 is not radically new and risky. No one criticizing it in general,  
vague, and by some reports misleading terms has produced specific  
evidence to the contrary.


But I'll go further, to call out what may be a disagreement over the  
proper function of standards bodies. I believe that standards bodies  
should synthesize well-studied, relevant research results,  
implementation extensions shipped for years in derived dialects, and  
pragmatic solutions to small bugs in the existing language defined by  
the standard body, when working on the next version of the standard.


Whatever the motivations of ES4 critics, the assertion that standards  
bodies should not host such collaborative, developer- and user- 
oriented work means in practice that big companies will dominate  
standards bodies, as I wrote here recently. That may be fine for pay- 
to-play consortia and their biggest (and best-paying) members. It is  
not good for developers, users, small and medium size vendors, or the  
public in general.


/be


___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Possibility of standardized sprintf() in ES4?

[Brendan Eich]

On Oct 28, 2007, at 4:39 PM, Dan Scott wrote:

> Ah, fabulous - it seems that although the term "sprintf" appears in  
> the wiki, it's highlighted and therefore doesn't turn up in a  
> search for the term. And I was too dumb to search for "string  
> format" -- thanks for letting me know that the issue had been  
> raised in the past and that there had been some discussion about it.

I'm not sure the wiki search indexing is working correctly atm. We'll  
look into it.

> In my view, it's simply a gap in the standard library (and I  
> apologize if this was not the correct forum to raise concerns about  
> the standard library vs. the core language spec).

No worries, for better or worse, ECMA-262 specifies both core  
language and standard library.

> As I noted at the outset, there are a wide variety of sprintf()  
> (and probably String.format()) implementations already out in the  
> wild under various licenses and with varying sophistication. I  
> believe that adding such a method to the standard library would  
> help simplify the current situation and increase the ease of  
> reusing code between projects.

But which one? Whose ox gets gored? What about l10n? Etc.

You can tell we didn't have the bandwidth to take this on, and with  
so many JS libs purveying variations on a theme, we chose the virtue  
of not committing the standard to one particular string formatting  
library. But no matter the timing, having a concrete proposal would  
help. Can you link to the Microsoft String.format API doc?
/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Brendan Eich]

On Oct 28, 2007, at 7:53 PM, Mark Miller wrote:

> I have now read the section of the overview document titled
> "Compatibility" and every embedded bold "Note:". Congratulations.
> Seriously.

Thanks. There are likely to be even fewer compatibility notes soon  
(see http://bugs.ecmascript.org/ticket/250 and http:// 
bugs.ecmascript.org/ticket/251).

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Implementor Question

[Brendan Eich]

On Oct 29, 2007, at 10:56 AM, Yehuda Katz wrote:

> Is there any reason browser vendors couldn't continue to ship the  
> old ES3 interpreter, and make it available for 

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Brendan Eich]

On Oct 29, 2007, at 2:05 PM, Brendan Eich wrote:

These are two of several features not in AS3, but AS3 is hardly the  
ne plus ultra of JavaScript. So again I think your question is  
skewed toward Adobe. Opera contributed ideas and solutions based on  
its experience.


As did other members of TG1, including Mozilla, of course. I hasten  
to add this, lest the open-spec conspiracy theory be enlarged to say  
Adobe, Mozilla, and Opera are trying to advance some hidden agenda.


/be___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Brendan Eich]

f many failed attempts to
work out well.

But even if you have succeeded at integrating together more good  
ideas

into a coherent language design than have many previous brilliant
language designers, I have another concern: Standards bodies  
should not

do de-novo design. And they especially should not foist a design as a
standard before there's a substantial track record of usage. How many
large systems have already been written in this proposed ES4  
design? E
is a much smaller language than ES3, but it has evolved  
substantially in

ways that surprised me, based on actual experience trying to use the
language.




[...] Brendan Eich
has repeatedly explained why a multiplicity of languages on the  
web is



infeasible, e.g. at the URL Jeff Dyer linked to
(http://lambda-the-ultimate.org/node/2504).


Are you referring to the post at
<http://lambda-the-ultimate.org/node/2504#comment-37607>? I'll  
wait for

a response before responding further to this point.



So obstructing the progress
of JS and consequently the open web in the name of preserving the
purity of a "platonic ideal" of JavaScript strikes me as either a
mistake of philosophical extremism, a convenient cover for  
conflicted

business interests, or a combination of both.


I have now learned ES3 itself quite well. I would not describe it  
as a
platonic ideal of anything. I think ES3 is already too large, and  
it has
many broken features (with, this-capture, pervasive mutability,  
lack of

encapsulation, silent errors, for/in loop dangers, ...).

The question we are discussing is which direction constitutes  
progress.

Your response assumes your conclusion. Language vendors and standards
committees, constrained by upwards compatibility, can only grow their
language. Once a language gets too large, the best that we can  
hope for

is that they grow it slowly, incrementally, and conservatively.

Java 1.5 came after Java 1.4, and it adds many features to Java 1.4.
All the additional features added are each individually arguably good
ideas, and recapitulate some of the elements of ES4's list. Does this
imply that Java 1.5 represents progress over Java 1.4? In this  
case, I
am quite familiar with the language both before and after. The  
process
by which 1.5 evolved from 1.4 was much more experience driven and  
much
more incremental than what I see here. Nevertheless, IMO, Java 1.5  
is a

substantially worse language that Java 1.4.

The "convenient cover for conflicted business interests" comment  
is the

sort of ad hominem nonsense that I hope we can avoid in further
discussions. I have known both Doug Crockford and Allan Wirfs- 
Brock for

years before they joined Yahoo and Microsoft respectively. The
suggestion that either would act with less than integrity in order to
serve their corporate interests, I find ludicrous and offensive.


Finally, just to reiterate that the "it's a different language"  
charge



glosses a critical aspect of the ES4 proposal, namely backwards
compatibility. ES4 is not a new language. It is, as the overview
describes, a significant evolution of ES3.


C++ is approximately backwards compatible with C. With a small number
of changes, it could have been precisely backwards compatible.  
Should we

consider C++ to be merely a significant evolution of C? The additions
that C++ makes to C are larger than the C language itself.
From the list from the ES4 abstract I quote above, I fear this  
may be

true of ES4 vs ES3.

--
Text by me above is hereby placed in the public domain

   Cheers,
   --MarkM
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss


___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Brendan Eich]

On Oct 29, 2007, at 3:05 PM, Ric Johnson wrote:

>> bad, because if I had, you would have heard another side to the
>> story, and a vigorous debate, and then probably we wouldn't be
>> playing this "how long have you been beating your wife?" game. Which
>> I refuse to play.
>
> Um... I am not accusing you or anyone. This is what was said at the  
> TAE,
> but not by me

Yes, but you're repeating what was said, including some assumed  
premises I want to argue about first.

> I did read it.  However, I do beleive Doug's quote was "half of the of
> the working group did NOT agree, but it is being pushed through
> anyway".  I wrote this down word for word at the time, but may have
> attributed incorrectly.

Wow, I can't tell what Doug said now, since he just today told me  
that he included Opera among the pro-ES4 sub-group, and 3 is greater  
than 2. Perhaps John Resig, who was on the panel, can testify. Not  
that we need to dwell on what Doug said :-/.

Since you are repeating more dubious claims, possibly from Doug, I'll  
repeat that TG1's majority outnumbers its minority, counting  
companies active over the last two years, by four to two. By people  
including invited experts, more like seven or eight to three. But in  
any event, this is an Ecma and potentially ISO issue, and unanimity  
is not required to make progress on a draft standard.

>> of being mentally dim. He called a press conference to deny the
>> allegation, which did not help. I'm not that dumb, so I'm going to
>> reject your question and ask you to justify its premise. If we don't
>> share premises, there's no point arguing conclusions.
>
> I never said you were dumb- quite the opposite,

That was supposed to be a humorous aside; never mind.

> but I fail to see how
> rejecting the question gets us anywhere.

See below about arguing premises before questioning anyone based on  
conclusions based on the premises.

>>> Can anyone else comment HOW either party would benfit if this did
>>> happen?
>>
>> Can you stop assuming your conclusion (Adobe/Mozilla conspiracy) for
>> a minute and examine its premise (which can be addressed by looking
>> at public materials on exactly who created ES4 as proposed in TG1)?
>
> I have reviewed quite a few docs, although I may have missed more.  I
> like ES4 and thank you for your hard work.  However, my question still
> stands.

If your question is about motives for companies in favor of ES4 as  
proposed, then I can answer only for Mozilla. If you are asking me to  
prove a negative -- to disprove a hidden agenda, a secret Adobe/ 
Mozilla (Opera/MbedThis/UC Santa Cruz/Northeastern University)  
pecuniary or other supposedly malign interest of some sort served by  
ES4, then you are laboring under a fallacy (can't prove a negative).

>> Frankly, I think you are approaching the claims that I've seen
>> attributed to Doug Crockford at The Ajax Experience a bit
>> credulously. Since I was not there to give the other side, or at
>> least one other side, let's back up from taking Doug's claims as
>> gospel truth and putting other groups on trial based on one person's
>> statements.
>
> You are correct sir:  I do respect Doug and thus lent weight to the
> argument, but I also respect John Resig, who was at the conference.  
> The
> differing opinions is why we are having these discussions.

My understanding is that John, who has not participated in TG1, did  
not try to rebut anything Doug said, but simply affirm that he was  
enthusiastic about JS2 and that Mozilla was committed to ES4.

Let's step back from personal authority and who said what. Mozilla's  
position, is that standards should address unmet use-cases and actual  
bugs in prior editions of a standard, and work to address them  
without a-priori restrictions on things like competitive positions in  
the market, or even size or "mood" of programming language as  
perceived by some of its fans. Standards should evolve in the open,  
sometimes rapidly, to incorporate sound research results and real- 
world feedback.

And make no mistake: JS developers have real problems using JS1/ES3  
at scale, both because of limitations in current implementations, and  
because of the small design of the language (see Guy Steele's  
"Growing a Language" talk, please!).

This is why Mozilla has invested in ES4.

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Brendan Eich]

On Oct 29, 2007, at 3:06 PM, Neil Mix wrote:


What would Adobe and Mozilla possibly have to make a "deal"
concerning?
Its probably the case that the head decision makers of Mozilla and  
the

head decision makers at Adobe have never met each other, much less
made
a "deal".


I'll play devil's advocate for a moment, and say "Tamarin".  It goes
like this: someone claims Adobe and Mozilla are in cahoots, and that
triggers the memory that Adobe open-sourced its AS engine to Mozilla,
and then the wheels start turning.  It's a lazy thought process, of
course, because what's really gained?  Did they team up to make sure
the spec results in as little modification to Tamarin as possible?
So they're teaming up out of laziness?  I don't get it either, but
you asked.


As the press release noted, Tamarin was open-sourced to share effort  
and accelerate development (and inform specification!) of a sound,  
implementable, high-performance ES4. I think I can say that without  
speaking too much for Adobe.


Also, and this is edgier: it's not as if Macromedia (remember, it was  
Macromedia who developed the VM originally) wanted to bear the cost  
of a high-performance VM all by itself. To add relevant information  
at the risk of dishing a rumor (sue me), I heard that Macromedia  
originally tried to license an existing small VM, and started on what  
became Tamarin only after being denied that license.


I'll also testify, as an outsider with no interest in Adobe, that the  
Adobe (originally Macromedia) employees on TG1 have always worked  
from shared principles and evidence to reach better design decisions,  
without regard for a corporate agenda. In particular, they've been  
willing to develop changes -- even if those changes inflicted  
incompatibilities on ActionScript users. I've heard this came at some  
political cost inside Adobe; it's not hard to imagine marketeers and  
evangelists there who might prefer a rubber-stamp.


But ES4 is not AS3, and it differs enough (see http:// 
wiki.ecmascript.org/doku.php?id=clarification:adobe_as3) that the  
claim that Adobe is forcing something it owns, without thoughtful  
changes, through a rubber-stamp process, is demonstrably false.  
(Rubber-stamped standards exist; you may have heard of OOXML?)


Of course Adobe desires to standardize, even at the cost of  
incompatibility. Reduced developer brainprint from variant dialects  
of JS is in their interest, and in their developers' interest. How  
nefarious.


/be___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Brendan Eich]

On Oct 30, 2007, at 10:49 AM, Mark Miller wrote:


On Oct 30, 2007 10:13 AM, Chris Pine <[EMAIL PROTECTED]> wrote:
Yes, I read that.  I am extremely doubtful that Microsoft is  
suddenly so
concerned about browser compatibility for the benefit of the web.   
(When

IE passes the Acid 2 test, let's talk again.)

It's nice that MS has constructed this document identifying browser
differences.  But frankly, this is too little, too late.  We are
painfully aware of the significant differences.  Suggesting that  
we all

sit down and strive to fix every last trivial discrepancy under the
guise of "browser compatibility" is manipulative and, from a business
standpoint, absurd.  It is an unnecessary task that would never be
completed.

In essence, it is just another stalling tactic.



When I raised non-technical points critical of the ES4 proposal,
people rightly shot back with a "technical discussion only!" response,


No, that's not what Rob Sayre wrote -- he said (in a later post) that  
you (among others) were trash-talking without any technical  
substance. Rob wrote:



I'm afraid your message falls into a pattern I've been seeing lately:
unsubstantiated, non-technical criticism. In other words, FUD.

If you have technical criticism to contribute, it is of course  
welcome.


That's different from saying "technical discussion only." It is not a  
demand for exclusively technical criticism. It is a request to stop  
unsubstantiated FUD.



which I've respected. Since then, most of the traffic on the list has
been non-technical criticisms of the critics of the ES4 proposal.


Guess why? Because the critics have made no technical objections on  
this list, and some carefully parsed (in Yehuda Katz's phrase; I  
wasn't there and I really can't tell what was said) statements about  
the politics and division within Ecma TC39-TG1 by Doug Crockford at  
last week's The Ajax Experience in Boston.


Of course people are going to argue about the political fight  
spilling out of TG1, and we may as well argue here. It's not as if  
pretending this political fight is not happening, or that it has no  
consequences on ES4, serves anyone's interest except those trying to  
stop ES4 from making it out of Ecma. It's not as if we have a better  
venue.



Much
of this traffic, such as the message I quote above, continues to
speculate about the motives of others, rather than engaging with what
they are saying.


Chris Pine is on TG1 and a witness to what's going on. He is not  
sowing unsubstantiated FUD, he is talking about what he has observed  
happening inside TG1, and giving his interpretation of it. He could  
be wrong, but his message is not simply speculation.


Politics inevitably involve motives and conflicts of interest, apart  
from purely "technical" concerns genuinely expressed. And as should  
be very clear by now, the objections to the proposed ES4 that TG1  
members have heard are either non-technical, or technical only in a  
vacuously general sense.



My comments, which provoked so much response,
contained no such speculation.


No, you merely called ES4 a train wreck and a runaway standard, by  
repeating what you heard from someone at OOPSLA. In my book, that's  
much worse than speculating about Microsoft's motives or business  
interests.


Please note that I'm not talking about individuals who work for  
Microsoft, many of whom are fine people who may hold sincere  
technical opinions about ES4 as proposed, or at least their  
understanding of it. I'm talking about the company's business  
interests, its strategies.


Microsoft's interests and strategies are absolutely critical to  
consider when developers ask about the future of ES4, as Kris Zyp  
just did -- and I am going to respond to him on this list. My  
response will contain technical as well as political content.



I can only conclude that, on this list,
the injunction "technical discussion only!" should be interpreted as
carrying the additional clause "unless you agree with us."


You never heard "technical discussion only", and no one ever demanded  
agreement with some mythical "us". You've made a straw man and  
knocked it down.


/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Brendan Eich]

On Oct 30, 2007, at 11:37 AM, Yehuda Katz wrote:


Sent from my iPhone


Twice :-/.


Begin forwarded message:


From: Yehuda Katz <[EMAIL PROTECTED]>
Date: October 30, 2007 11:26:58 AM PDT
To: Michael O'Brien <[EMAIL PROTECTED]>
Cc: es4-discuss 
Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE  
ALARM


I spent all of yesterday writing code in ES4 but the current state  
of the RI is so crippling as to make it a fairly useless tool for  
exploring how one would really write ES4 code.


The RI is working well, but for reasons I should have paid more  
attention to, the snapshot at http://www.ecmascript.org/ is out of  
date, as you say. I think it should be udpated soon, even if it does  
not track the overview document yet. I'm working on this. Apologies  
for the hassles.


/be


___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Number handling

[Brendan Eich]

On Oct 30, 2007, at 12:55 PM, Yehuda Katz wrote:

> After playing with the ES4 RI yesterday, my biggest concern comes  
> from the handling of various number types as compared to other types:
>
> * Literal numbers become ints, rather than Numbers. While ES4 is  
> still compatible with ES3 via some very strange use of the  
> constructor property, doing something like: var x:Number; x = 7;  
> throws an error.

As noted, an RI bug (apologies again). The ES4 proposal calls for  
interconversion among the types in AnyNumber.

> * ints are coercive by default. So function foo(x:int) { return  
> x }; foo(null) returns 0, while function foo(x:Number) { return  
> x }; foo(null) returns null. In effect function foo(x:int) { return  
> x } is identical to function foo(x:*) { return new int(x) }

More RI bugs. See http://bugs.ecmascript.org/ticket/113.

> * This is the same for all "primitives" like double.

When fixed (some of the problem has been fixed already), only for all  
members of AnyNumber. Current RI:

$ make repl
perl bin/repl-with-readline.pl
 >> var i:int = 3.14
 >> var j:double = 7
 >> var k:int = "moo"
[locn] builtins/Error.es:86:55-86.55
[stack] [init k()]
**ERROR** EvalError: uncaught exception: TypeError: incompatible  
types w/o conversion: val="moo" type=[ns public '__ES4__']::string   
wanted=[ns public '__ES4__']::int  (near builtins/Error.es:86:55-86.55)
 >> var l:double = "oink"
[stack] [init k() | init l()]
**ERROR** EvalError: uncaught exception: TypeError: incompatible  
types w/o conversion: val="oink" type=[ns public '__ES4__']::string   
wanted=[ns public '__ES4__']::double  (near builtins/Error.es: 
86:55-86.55)
 >>

> Of course, it's possible that some of this is just a failing in the  
> reference implementation, but looking through the available  
> materials leads me to believe that it's not *all* RI-related.

It is all RI-related, sorry again. The proposals and especially the  
overview are clearer about interconversion only among AnyNumber  
members. And ticket 113 is there to remind us.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Brendan Eich]

[Kris asks legitimate questions, to be answered by more than a  
Microsoft spokesperson. I'm going to reply cc'ing the list, even  
though there are political points here along with technical content.  
The list is for discussion of ES4, and that category looks like it  
must include some political discussion.


 Also, this reply is LONG. Sorry, I've tried to compress without  
doing anyone an injustice.


 Skip if you want to avoid any political content. If you think I'm  
FUDding or attacking individuals unfairly, call me on it -- with  
specific quotations if possible. If I'm out of line, I'll apologize   
to the list and amend my words. If we simply disagree on the  
fundamental substance, that's good to know too.


 I'm trying to shed some light on what has clearly been too much of  
a dark-room standards process, excluding the materials we've exported  
at http://ecmascript.org/.


/be]

On Oct 30, 2007, at 9:17 AM, Kris Zyp wrote:

From a pragmatic perspective, it seems to that the critical goal  
behind all of this, is what will bring a better development  
environment for the future of the web, and the key to this is what  
will be broadly implemented. The choice of the name is of course  
around this central issue since the ES title brings such a strong  
motivitation for implementation. However, if ~10 years


Try two years -- ten is way, way too long for developers to wait, and  
anyway beyond any credible crystal ball's range. The proprietary  
stacks from Microsoft and Adobe won't wait that long for competition  
from browser-based web standards, as Doug Crockford and others warn;  
they'll propagate all over the web well before ten years.


down the road, ES4 is not implemented broadly enough that web  
developers can code to it, than it is of signficantly less value.  
While unanimity is not needed for a standard to be passed, if the  
one of the key browser vendors will not implement it, than how  
valuable are our efforts?


Let's find out, by having a standard that browsers and plugins can  
choose to implement for interoperability and shared developer  
knowledge. Enough companies want ES4 as a standard that (absent  
technical problems), it ought to become one, whether or not all  
browser vendors buy into it.


If you give all the power over standardization to any one company,  
then you are that company's slave, and I predict you'll get treated  
accordingly. This happened once already, after IE achieved a virtual  
monopoly. Just consider all the unfixed JScript bugs, many dating to  
IE4, still in IE7.


 I know that there are, or will be efforts to provide a Tamarin  
plugin for other browsers, but is this really what we are pinning  
our hope on?


Not necessarily, but (hey, I came up with it ;-) it's not a bad plan  
absent competitive pressure on Microsoft to support ES4 in IE.


You may not know this, but minority-share browsers do not have as low  
market share as the Comscore and WebSideStory analytics firms'  
results show in aggregate for the U.S.. At high value sites, visited  
more frequently by "lead users" and otherwise influential (and better- 
monetized) visitors, Firefox, Safari, and Opera do better --  
sometimes much better. If you look at Xiti's results for Europe,  
Firefox is trending to cross the 50% market-share line in some  
countries.


Whatever you do, never give up your own sovereignty as a browser user  
or a web developer to a dominant player. You always have a choice.


Plugins usually don't reach necessary distribution for developers  
to rely on them.


Counterexample: the Flash Player.

I have no idea whether Flash would ship ScreamingMonkey support. I  
certainly hope so, given Microsoft's rejection since early this year  
of ES4.


Or are we hoping that the ES4 title will be sufficient to get an  
implementation from every vendor?


Title, schmitle. :-) The "brand value" of ES4 may be an issue for  
browser vendors, but it is not the main issue for developers, and  
users don't know or care. What matters is whether web developers can  
effectively demand, and count, on near ubiquity and quality from ES4  
implementations, soon (a year or two). That is an open question, as  
noted above -- and there are several reasons to have hope.


I certainly acknowledge that it is insidious that there might a  
suggestion to design around one member, but I will still ask, is  
there any concessions that can be made to increase the probability  
that MS would implement ES4 in the future?


No. Without speaking for anyone else, I am now going to give more  
information about what has already been said inside TG1, since the  
TG1 dispute has already spilled out into the blogosphere since last  
week's Ajax Experience East, when as part of a panel discussion, Doug  
Crockford made some statements about TG1 members and motives. Others  
in TG1 can back this up, and anyone can check our meeting minutes,  
which are public at http://wiki.ecmascript.org/ with complet