RE: ECMAScript Harmony

[Allen Wirfs-Brock]

> I think Allen Wirfs-Brock was in favor of merging the lists, but we
> could just rename es4-discuss to es-discuss. Is it worth dropping
> that 4?
>

I think that "es-discuss" is a lot more "future proof" and now is as good a 
time to change as any.

As I've already mentioned to Brendan, I think it may be useful in the long term 
to separate detailed discussion of the "next" revision from longer term or 
speculative discussions.  However, for now, we need to rebuild a single 
community and most of the ES3.x-discuss items are getting (or should be) cross 
posted to es4-discuss anyway. Given that, I think we should just merge the 
lists and if we find that 3.1 and post 3.1 items are getting intermingled in a 
confusing manner we can always split it out again.  I suppose one way to 
preserve that option is for everyone to just stop posting to ES3.x-discuss and 
only post the new es-discuss.

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

Notes from 8/7 ES3.1 Teleconference

[Allen Wirfs-Brock]

Attending: Allen Wirfs-Brock, Douglas Crockford, Mark Miller, Sam Ruby

Topic: Review and Discuss name changes and additions to Object meta functions 
in 8/04 Draft.

Summary of 8/04 changes:
Rename Object.getProperty(o,p) to Object.getPropertyDescriptor(o,p)
renamed Object.const (o) to Object.freeze(o)
renamed Object.isConst(o) to Object.isFrozen(o)
added Object.nonExtensible(o)   /*sets an object's internal [[Extensible]] 
property to false.*/
added Object.isExtensible(o)   /* returns current state of an object's  
internal [[Extensible]] property */

Discussions:
getProperty change
Mark argues that for consistency it should be getOwnPropertyDescriptor
(after the meeting, Allen verified that there is an revision error in the 7/15 
and 8/04 drafts that resulted in Object.getOwnProperty and Object.getProperty 
both existing with the same definition.  The intent was to remove 
Object.getProperty so renaming Object.getOwnProperty to 
Object.getOwnPropertyDescriptor is the change that should have been made for 
the 8/04 draft).
Mark expressed concerns about the length of getOwnPropertyDescriptor.  Allen 
reminded  that getOwnProperty can be interpreted ambiguously as to whether it 
is retrieving a property value or a property descriptor (see previous thread on 
es4-discuss). Allen also argued that a long descriptive name  is not 
necessarily bad for specialized a function that is intended for use by a 
limited audience.
Actions:
rename Object.getPropertyDescriptor to Object.getOwnPropertyDescriptor
delete Object.getOwnProperty

Object.const/Objct.isConst renaming
No controversy, everybody was happy with these changes
Actions: none

Added Object.nonExtensible(o)
Nobody is particularly happy with this name.  It's not clearly imperative or 
interrogative. Other possibilities discussed included; notExtensible,  
noExtensions, disallowExtensions, noNewProperties, close, limit, bound, 
preventExtensions. The first few have the same problem as nonExtensible. The 
words close, limit, and bound are either too general, have possible unintended 
semantic interpretations, or are too useful for other purposes. Favorites seem 
to be disallowExtensions and preventExtensions with preventExtensions being 
slightly preferred.
Action: rename Object.nonExtensible to Object.preventExtensions

Added Object. isExtensible()
No controversy, everybody was happy with the addition and name.
Actions: none

Topic: Should Object.keys be repositioned as Object.prototype.keys
Discussion: Allen argued that this isn't really a meta layer operation as it is 
intended for use in application layer code as an alternative to for..in for 
getting a list of enumerable property names. As a application layer method it 
belongs on Object.prototype rather than on the Object constructor.  There was 
general agreement in principle, but it was pragmatically argued by Doug and 
Mark that it is too likely that a user defined object would define its own 
property named "keys" which would shadow Object.prototype.keys making it 
inaccessible for use on such objects.
Action: Leave it as Object.keys.

Topic: Since there is no long an potential ES4 conflict should the name of the 
"flexible" property attribute revert to the originally proposed name "dynamic"?
Discussion: Some possible alternative names:
   dynamic - What it was going to be called until a conflict with 
ES4 proposal developed
   sealed  - corresponds to the name of the operation that turns it 
off for all properties of an object
   fixed - another name similar to sealed
Mark no longer likes dynamic because of possible unintended interpretations 
such as dynamically scoped. Sealed and fixed diverge from the new attribute 
naming pattern which is to use a name that describes the more permissive state 
of boolean attributes or internal properties (eg, writable, enumerable, 
extensible). Flexible has the advantage that it probably doesn't carry with it 
any semantic preconceptions.
Action: Leave it as "flexible"
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

To answer Garrent's questions I was going to directly quote the specification 
in the July 15 draft ES3.1 specification, but I found that that version had 
some issue in following the specification conventions.  So here is what the 
definition of Object.create should be:

15.2.3.6Object.create ( O [, Properties] )
The create method creates a new object with a specified prototype. When the 
static create method is called, the following steps are taken:
1.  If Type(O) is not Object throw a TypeError exception.
2.  Create a new object as if by the expression new Object() where Object 
is the standard built-in constructor with that name
3.  Set the internal [[Prototype]] property of Result(2) to O.
4.  Call the standard built-in function Object.defineProperties with 
arguments Result(2) and Properties.
5.  Return Result(2).
The length property of the Object.create function is 1.

> -Original Message-
> From: Garrett Smith [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 18, 2008 6:21 PM
> To: Allen Wirfs-Brock
> Cc: es4-discuss@mozilla.org
> Subject: Re: ES3.1 Object static methods rationale document
>
> On Fri, Jul 18, 2008 at 2:02 PM, Allen Wirfs-Brock
> <[EMAIL PROTECTED]> wrote:
> >> -Original Message-
> >> From: [EMAIL PROTECTED] [mailto:es4-discuss-
> >> [EMAIL PROTECTED] On Behalf Of Garrett Smith
> >> Sent: Friday, July 18, 2008 12:28 PM
> > ...
> >> You're prev response seems to have come from the discussion of
> >> Object.create. Object.create, with only one argument, is the same as
> >> beget. The beget function makes a new object that inherits members
> >> from an existing object. The rationale doc fails to make mention of
> >> this.
> >
> > See the first complete paragraph on page 13
> >
> "Note that Object.create without its optional second argument is
> essentially the same operation as
> the beget function that was been widely promoted. We (perhaps not
> surprisingly) agree with the
> utility of this function but felt that the word "beget" is probably
> confusing to many non-native English
> speakers."
>
> Does object.create add an object to the first argument's prototype
> chain? That's not explicitly stated, and one has to hunt down Doug's
> begetObject. (below)
>
> Does the propertyDescriptor describe an object added to the front of
> the object's prototype chain?
>
> =
> Object.prototype.begetObject = function () {
> function F() {}
> F.prototype = this;
> return new F();
> };
>
> Lasse Reichstein Nielsen's "clone" function, c. 2003:-
> Object.prototype.clone = function () {
> function myConstructor = function(){};
> myConstructor.prototype = this;
> return new myConstructor();
>  }
> =
> http://groups.google.com/group/comp.lang.javascript/browse_thread/threa
> d/0c1cc7f1cb314f8e/5d06e72e55d5bf11?#5d06e72e55d5bf11
>
> Garrett

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

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

> -Original Message-
> From: Garrett Smith [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 18, 2008 10:31 AM
...
> >
> > Neither Object.create nor Object.clone was not intended to be a
> directly replacement for Object.extend.
>

Make that:
Neither Object.create or Object.clone were intended to be a direct 
replacement for Object.extend.
Or
Object.create and Object.clone were not intended to directly replace 
Object.extend.
My brain clearly hadn't decided which formulation it was trying to spew.

The reason I would say either of the above, is that I think of both 
Object.create and Object.clone as primarily object instantiation functions 
(factories, if you prefer) and that my preference is to factor common 
behavioral properties (eg, methods and getters/setters) into shared "parents" 
on the prototype chain rather than copying them into multiple instances. 
Similarly, my preference for "data" properties (eg instance variable) is to 
define them when an object is first instantiated, rather than lazily as they 
are assigned to.  (BTW, these preference are significantly influences by the 
optimization opportunities they create for a smart implementation)

To get more concrete, if I was going to implement the ECMAScript equivalent of 
a classic point abstraction, I would define a point parent containing all the 
methods.  For example:
   const pointBehavior = Object.defineProperties({}, {
  add: {
enumerable: false, writable: false, flexible: false,
value: function (aPoint} {/**function body omitted**/
}},
  distance: {
enumerable: false, writable: false, flexible: false,
value: function (aPoint} {
/**function body omitted**/
}},
  /** other methods ***/
});

And for the public point factory, I would either define an instance template 
object (I need to say template because the word "prototype" has too many 
possible interpretations in the world of ECMAScript) that gets cloned:
   const pointTemplate = Object.create(pointBehavior, {
  x: {value: 0, enumerable: true, writable: true, flexible: false},
  y: {value: 0, enumerable: true, writable: true, flexible: false}
  });
   function makePoint() {return Object.clone(pointTemplate)};

or I would just use create in the factory function:
   function makePoint2() {
  return Object.create(pointBehavior, {
 x: {value: 0, enumerable: true, writable: true, flexible: false},
 y: {value: 0, enumerable: true, writable: true, flexible: false}
 });
  }

or I might must inline the definition of pointBehavior into the above and get:
   function makePoint3() {
  return Object.create(
 Object.defineProperties({}, {
//methods
add: {enumerable: false, writable: false, flexible: false,
   value: function (aPoint} {/**function body omitted**/
   }},
distance: {enumerable: false, writable: false, flexible: false,
  value: function (aPoint} {/**function body omitted**/
   }},
/** other methods ***/
},
 {
//instance variables
x: {value: 0, enumerable: true, writable: true, flexible: false},
y: {value: 0, enumerable: true, writable: true, flexible: false}
}
 );
  }

Now, I admit that I'm using Object.create to define the template object and 
that I could have used it to define the behavior object, but I rationalize that 
to myself as the act of instantiating a couple of singleton objects so I'm 
still using Object.create primarily as an instantiation function. Regardless, 
my sense that this style is different from what people are talking about WRT 
using Object.extend for injecting mix-in behaviors.

BTW, please consider the above to be part of my answer to essay question #3 
that I posed in an earlier post today.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:es4-discuss-
> [EMAIL PROTECTED] On Behalf Of Garrett Smith
> Sent: Friday, July 18, 2008 12:28 PM
...
> You're prev response seems to have come from the discussion of
> Object.create. Object.create, with only one argument, is the same as
> beget. The beget function makes a new object that inherits members
> from an existing object. The rationale doc fails to make mention of
> this.

See the first complete paragraph on page 13
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:es4-discuss-
> [EMAIL PROTECTED] On Behalf Of John Resig
>
> No? We've been discussing the viability of a new Object.extend() method
> to be introduced in ES3.1. Mozilla has offered a proposal and is
> looking to implement it in SpiderMonkey. I provided examples of
> Object.extend-like functionality in the wild and coupled it with a
> sample pure-JavaScript implementation and some test cases.
>
>...

John,
Just to be clear, I haven't seen your proposal and this is the first time I've 
seen explicit mention that you were actually going to make a proposal for the 
addition of Object.extend to 3.1.  I thought that we were generally discussing 
how Object.extent related to the Object meta functions that are already in the 
3.1 draft. Now, it may just be that I somehow missed the proposal when it came 
by, or that the intent was implicit in some of your or Brendan's posts.  Either 
way, it just wasn't obvious.  Regardless, certainly feel free to make the 
proposal.  Ideally, for inclusion in the 3.1 spec. it should follow the 3.1 
specification methodology.

Allen


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

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

Object.getProperties and Object.getOwnProperties were part of the early design 
of thiss set of functions.  See for example, the June 24 draft at 
http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft

I proposed removing them, because I felt that they were starting to impinge 
upon the territory that might be occupied by a high-level, mirrors-style 
reflection model (see http://bracha.org/mirrors.pdf )  for ECMAScript.  I would 
like to avoid that  because I think a comprehensive mirror reflection model is 
something we might, over the long term, want to considering adding to 
ECMAScript.

You can see the potential conflicts a couple of places.  As currently defined, 
the property descriptor and property descriptor set objects are pure data 
records.  They have no behavioral properties. If you latter wanted to extend 
them to be mirror objects they would have to add methods and, at least for the 
property set descriptor, there would be issue with such method names 
conflicting with the names of reflected properties. The other place you see it 
is with getProperties which had been specified to return a flattened set of 
properties (flatten as in nothing distinguished own from inherited properties). 
In a generalized reflection model you would definitely what to have access to 
such "inheritance" information, for example by grouping properties by prototype 
or by tagging each individual property with inheritance information.

We ultimately concluded that the best way to think about what we are currently 
provide is that it is a set of primitive mechanisms that could be used to build 
higher level reflection facilities. If we had a strong use case we could 
reintroduce getOwnProperties as such a primitive, but so far it seem 
non-essential.  Incidentally, when we removed getOwnProperties we had to add 
getOwnPropertyName because otherwise you won't necessarily know what properties 
to ask for using getOwnProperty

-Original Message-
From: Igor Bukanov [mailto:[EMAIL PROTECTED]
Sent: Friday, July 18, 2008 8:15 AM
To: Allen Wirfs-Brock
Cc: John Resig; es3 x-discuss; es4-discuss@mozilla.org; Mark S. Miller; Robert 
Sayre
Subject: Re: ES3.1 Object static methods rationale document

2008/7/18 Allen Wirfs-Brock <[EMAIL PROTECTED]>:
> Collectively, 
> getOwnProperty,defineProperties/defineProperty,getOwnPropertyNames,getPrototypeOf
>  are intended to provide all the mechanisms necessary to build any of these 
> variants to extent or any other model of property manipulation using whatever 
> policies for property selection that might be desired by the designer.

This suggests to have a convenience method like getOwnProperties that
return an array of ptoperty descriptor for the object. It would allow
a user to define a simple form of the extend method as:

  Object.defineProperties(destination, Object.getOwnProperties(source));

It would also allow to define Object.clone(source) precisely as

  Object.create(Object.getPrototypeOf(source), Object.getOwnProperties(source));

Which in fact shows that Object.clone is in the same category as
Object.extend. Both methods defines very particular arrangement of
properties in the object and less fundamental than the rest sets of
the methods.

Regards, Igor

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

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

John,

Thanks for pulling together all the various versions of Object.extend.  It's 
useful to have them in one place.

There are a couple of things you mentioned that I wanted to clarify.

Neither Object.create nor Object.clone was not intended to be a directly 
replacement for Object.extend.  The more direct comparable would be 
Object.defineProperties.  Object.create's heritage is Doug Crockford's beget 
function and its primary purpose is to provide a more direct way to create an 
object with an explicitly specified prototype.  Other than for atomicity and 
any optimization that an implementation might be able to perform 
Object.create(parent,properties) is exactly equivalent to 
Object.defineProperties(Object.create(parent), properties). Object.clone is 
just a "shallow copy" and its primary use case is exact copies of objects.

Object.defineProperties is comparable to Object.extend in the sense that it 
injects a set of properties into an already existing object.  It is different 
from Object.extend in that rather than copying the injected property directly 
from a source object, it uses a meta level description of the properties to be 
injected.  It is more general, in that it can inject properties with any 
attribute settings and allows control of attribute values at the per attribute 
per property level.

It may be useful to think of defineProperties as defining a mechanism for 
copying properties but without defining a fixed policies concerning which 
properties to copy.  In contrast, Object.extend applies a specific policy for 
copying.

Collectively, 
getOwnProperty,defineProperties/defineProperty,getOwnPropertyNames,getPrototypeOf
 are intended to provide all the mechanisms necessary to build any of these 
variants to extent or any other model of property manipulation using whatever 
policies for property selection that might be desired by the designer.

I'll exit with three essay questions:

Is the formulation and policies of Object.extend the ideal, or is it simply the 
best that could be accomplished given the available reflective capabilities of 
ES3 (or extended ES3 in the case of getter/setter properties)?

Are there any essential meta-level function that would be needed to implement 
anything like Object.extend that are missing from the proposed set of 3.1 meta 
operations?

Let's assume that defineProperties was available and we have a  green-field 
situation where somebody is creating a framework that needs to use some sort of 
property mix-in process. Do you think its developer would still implement their 
own version of Object.extend and specify their mix-ins as conventional objects, 
or would they just use defineProperties and specify their mix-ins as property 
descriptor sets?

-Original Message-
From: John Resig [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 17, 2008 8:38 AM
To: Allen Wirfs-Brock
Cc: es3 x-discuss; es4-discuss@mozilla.org; Robert Sayre; Mark S. Miller
Subject: Re: ES3.1 Object static methods rationale document


I wanted to bring up some further evidence for the widespread use of an 
extend() method. Here are the top 5 JavaScript libraries and their associated 
versions of "Object.extend()":


== jQuery.js:

(jQuery also does deep extend - but that isn't relevant here.)

jQuery.extend = jQuery.fn.extend = function() {
var target = arguments[0] || {}, i = 1, length = arguments.length, 
options;

if ( typeof target != "object" && typeof target != "function" )
target = {};

if ( length == i ) {
target = this;
--i;
}

for ( ; i < length; i++ ) {
if ( (options = arguments[ i ]) != null ) {
for ( var name in options ) {
target[ name ] = options[ name ];
}
}
}

return target;
};


== Prototype.js:

Object.extend = function(destination, source) {
  for (var property in source)
destination[property] = source[property];
  return destination;
};

== Mootools.js:

var $extend = function(){
var args = arguments;
if (!args[1]) args = [this, args[0]];
for (var property in args[1]) args[0][property] = args[1][property];
return args[0];
};

== Dojo Toolkit:

dojo._mixin = function(obj, props){
var tobj = {};
for(var x in props){
if(tobj[x] === undefined || tobj[x] != props[x]){
obj[x] = props[x];
}
}
// IE doesn't recognize custom toStrings in for..in
if(d["isIE"] && props){
var p = props.toString;
if(typeof p == "function" && p != obj.toString && p != 
tobj.toString &&
p != "\nfunction toString() {\n[native code]\n}\n"){
 

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

The fixture question is a good one, but takes some thought to answer well so 
I'm not going to tackle it until tomorrow.

The other questions are easy:

1) as currently specified, unrecognized properties of a property descriptor are 
ignored.
2) no, in your example, the value of the o1 property of the created object 
would be an object that looks like a property descriptor.

From: Garrett Smith [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 9:17 PM
To: Allen Wirfs-Brock
Cc: es4-discuss@mozilla.org
Subject: Re: ES3.1 Object static methods rationale document


2008/7/15 Allen Wirfs-Brock <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>>:
> I've up loaded to the wiki a new document titled:  "Proposed ECMAScript 3.1
> Static Object Functions: Use Cases and Rationale"
>
>

A couple of questions for you:

My first question: How does an ES3.1 "sealed" object relate to fixtures?

__| ES 3.1 __| ES4___
Sealed object | Object.seal  | fixture (var)

My second question is about Object.create. Object.create() mixes adding a 
prototype to an object with a
specialized context where the (verbose) object literal contains certain 
property names, such as "value", take on contextual meaning to the property.

1. What happens when an unrecognized property is in the descriptor? (1)
2. Is it only possible to define attributes on the top level? (2)

(1)
Object.create(myProto, {
 method3: {
   enumerable: false, writable: false,
   novalue : true // no [[value]] + custom attribute
 },
 ,method2: undefined
});

(2) Object.create(myProto, {
 o1: {
   enumerable: true, writable: false,
   value : {
 enumerable : false,
 value : undefined
   }
 }
});

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

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

Object.create does not support changing the [[Prototype]] of an already 
instantiated object, if that was the question.  It creates a new object with a 
caller specified [[Prototype]] value.  Dynamic modification of an already 
instantiated object's [[Prototype]] is not something that I'm ready to advocate 
for. I believe that the single argument form has the same semantics as 
Crockford's beget function, however it need not be implemented in the same 
manner that Doug uses for beget.

The two argument form also adds the specified own properties to the new object. 
It's probably fair to say that a completely unoptimized implementation of this 
form would be O(n) on the number of properties.  However, I believe that 
Object.create is highly amendable to optimization.  In particular, cases with 
the properties descriptor is specified as an object literal consisting only of 
literal values (including many function expression) might be implemented to 
operate in near constant time.  Note that the same would be true if the second 
argument had been specified as being an object whose properties are to be 
directly copied (essentially making it somewhat more similar to the 
Object.extend function) and the argument is specified using an object literal. 
However, as the use of property descriptors proves the ability to specify the 
attributes of the copied properties in addition to their values.

-Original Message-
From: Kris Zyp [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 10:15 PM
To: Brendan Eich; Allen Wirfs-Brock
Cc: [EMAIL PROTECTED]; es4-discuss@mozilla.org
Subject: Re: ES3.1 Object static methods rationale document


>> Arguably, some of the need for direct prototype access is
>> alleviated by providing the clone method.  However, there are still
>> plenty of other situations where it is useful.
>
> I observe that __proto__ in SpiderMonkey- and Rhino-based JS is
> mostly used for cases covered by Object.create, with a minority use-
> case that we've discussed before initializing it to null in object
> initialisers to make maps (dictionaries).

I am curious how Object.create covers this __proto__ use case of making
objects with a defined proto. Doesn't Object.create create a new object and
copy properties over? __proto__ allows objects with existing properties to
have their proto defined in constant time, but isn't Object.create still
O(n), with n being the number of properties?

Kris


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

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

Object.clone is really just what is sometimes called a shallow copy. I would 
expect it to be most commonly used to make copies of objects that are mostly 
statefull, not for moving behavior around.

If you have one or more mix-ins that you want to directly add to a objects, I 
would use defineProperties.  Generally, one defineProperties per mixin although 
you could also use defineProperties to compose a number of such mix-ins into a 
composite which you then injected into objects as a unit.

However, I don't think I would normally want to do a lot of that sort of 
property injection, at least not for behavioral properties. (augmenting host 
objects is probably an exception to that) The cheapest way to provide behavior 
to multiple objects should be via their prototype chains.  Object.create make 
it easy to do that and it can also be used to linearize a set of mix-ins into a 
prototype chain.   For example, assume that a,b, and c are property set 
descriptors for 3 mix-ins.  You can linearize them by:

var newParent = Object.create(Object.create(Object.create({},c),b),a);
and then create instances with that behavior by doing something like:
return Object.create(newParent,perInstanceProperties)

The Es3.1 draft currently says that the effect of Object.clone is 
implementation defined for host objects.  That's because I've had it beat into 
me (mostly by people on this list) that host objects get to set their own rules 
and that there is nothing we can do about it. Personally, I'd be more demanding 
upon the integration of host objects but, as I can imagine  Brendan saying, 
that ship sailed ten years ago.

-Original Message-
From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 5:50 PM
To: Allen Wirfs-Brock
Cc: Robert Sayre; Mark S. Miller; [EMAIL PROTECTED]; es4-discuss@mozilla.org
Subject: Re: ES3.1 Object static methods rationale document


On Jul 16, 2008, at 4:10 PM, Allen Wirfs-Brock wrote:

> The most common use case seems to be the one where the target object
> is a newly instantiated object without any properties of its own.
> That use case (at least for variants of extend that only take a
> single source object) is most directly supported by the Object.clone
> function in our proposal. However, Object.clone is defined to be a
> more comprehensive object duplication process than is performed by
> extend.  It duplicates all own properties and their attributes and
> any internal properties such as its [[Value]] property if it has one.

1) It seems like Object.clone as you have described it is not suitable
for the "mixin" type use case where an object gets properties/methods
from two others. Or at least, it only does half the job.

2) Is Object.clone expected to work on host objects (in particular DOM-
related objects)? I think thorough cloning of all state is not a
practical semantic in that case, and would be a very large burden on
implementations. In the case of some classes (Window or Location for
instance) allowing true cloning might even be a security risk. And if
it does not support host objects then copying internal state like the
[[Value]] or [[Class]] property for ES standard object types will be
more confusing than helpful.

Regards,
Maciej


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

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

As far as I can recall, we didn't discuss a specific formulation that 
corresponds to Object.extend but we have considered (and arguably provided) 
pretty much equivalent functionality in our proposal. I assume that at least 
Doug, Adam, or Kris were specifically aware of Object.extend and would have 
broad it up if it was relevant.  One reason, it probably wasn't was that the 
starting point of our design was the full reification and control of properties 
and their attributes rather than just copying properties. By the time we got 
around to cloning/copying issues we already had establish some core elements of 
our overall design.

Doing a bit of search I've found several different variants of the extend 
function.  Some are defined on Object, some on Object.prototype.  Some use a 
single source object and some use multiple source objects.  What they all seem 
to have in common is that they copy the enumerable methods from one (or more) 
object to another.

The most common use case seems to be the one where the target object is a newly 
instantiated object without any properties of its own. That use case (at least 
for variants of extend that only take a single source object) is most directly 
supported by the Object.clone function in our proposal. However, Object.clone 
is defined to be a more comprehensive object duplication process than is 
performed by extend.  It duplicates all own properties and their attributes and 
any internal properties such as its [[Value]] property if it has one.

I have personally considered whether there should be some sort of mechanism to 
filter the properties copied by Object.clone.  For example, you might only copy 
non getter/setter properties, or only enumerable properties, or perhaps filter 
out ReadOnly properties. However, I never proposed any of these for the ES3.1 
spec. because I have yet to find a use case that was sufficiently compelling or 
pervasive enough to justify making the interface to Object.clone more complex 
(in contrast, see the explanation in the rationale document for why we added a 
second argument to Object.create).  If you want to do that sort of filtering 
you can do it using Object.wontbecalledgetProperty and Object.defineProperty.  
If you just want a fast and comprehensive copy use Object.clone.

The other obvious use case would seem to be adding some "mix-in" behavior to an 
object (some of the descriptions of extend on the web call this "inheritance" 
but it's not how I'd use that term).  This use case is fairly directly 
supported by Object.defineProperties although it is formulated somewhat 
differently.

As I mention in our rationale document, this design isn't just a set of 
individual functions but an attempt at a unified design where we have tried to 
distribute the functional elements across of set of related functions that 
often have multiple uses.  Object.extend is a fine function, particular when 
viewed from the perspective of what can be accomplished using the available ES3 
APIs. However, it isn't something I would simply add as whole cloth to the set 
of functions we have already worked out.  That would mostly just added 
redundant functionality and in a manner that wasn't particularly consistent 
with the other functions we have defined.  Instead, if we added it we would 
potentially refactor the functionality of all of the proposed static Object 
functions to make them stand together as a unit. I'd be happy to discuss 
additional use cases to see try to see if we can find any significant hole in 
our proposal.

Finally, I want to say that my approach to a situation like this where there 
appears to be multiple versions of a similar but not identical function is not 
necessarily to pick one and make everybody else conform.  Instead, I like to 
approach the problem from the perspective of what would have made these various 
functions unnecessary and what primitives would have been useful in 
implementing the assorted variations. If I can provide that then future users 
are unlikely to need to use the old forms and existing user can migrate by 
continuing to use their old API but perhaps reimplementing them using the new 
primitives.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Sayre
Sent: Wednesday, July 16, 2008 2:17 PM
To: Mark S. Miller
Cc: es4-discuss@mozilla.org; [EMAIL PROTECTED]
Subject: Re: ES3.1 Object static methods rationale document

Maybe someone could just give the rationale for leaving out Object.extend?

Douglas Crockford wrote that it was considered, but I'm confused since
it looks like you haven't even seen a proposal, and didn't participate
in the discussion to exclude it.

- Rob

2008/7/16 Mark S. Miller <[EMAIL PROTECTED]>:
> On Wed, Jul 16, 2008 at 10:11 AM, Brendan Eich <[EMAIL PROTECTED]> wrote:
>>
>> And? The doc gives rationales for design decisions. What's the
>> rationale for leaving Object.extend out?
>
> If the document needs to give rationa

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

Just wait, "reify" may yet end up as the last name standing...

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brendan Eich
Sent: Wednesday, July 16, 2008 2:27 PM
To: David Flanagan
Cc: es4-discuss@mozilla.org es4-discuss
Subject: Re: ES3.1 Object static methods rationale document

On Jul 16, 2008, at 1:41 PM, David Flanagan wrote:

> Brendan, I think you were correct when you originally wrote:
>
>> lookup : define :: get : put.
>
> I think that lookupProperty is much nicer than describeProperty, since
> "lookup" captures the getter nature of the method in a way that
> "describe" does not.


Connotations are many, ambiguity without a noun phrase (not just
overloaded old "property") saying what's being "got" or "described"
or "looked up" is inevitable. This means the stolid, safe name
"getPropertyDescriptor" is least likely to confuse.

I see what you mean about describe in the context of setting a
description (depict in a graphics context is problematic too) --
thanks. Thesaurus doesn't include mental concept filtering, dammit.
I'm sure we'll get this right, but I'm also pretty sure "getProperty"
isn't the droid we are seeking.

/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

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

Working...

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Sayre
Sent: Wednesday, July 16, 2008 2:17 PM
To: Mark S. Miller
Cc: es4-discuss@mozilla.org; [EMAIL PROTECTED]
Subject: Re: ES3.1 Object static methods rationale document

Maybe someone could just give the rationale for leaving out Object.extend?

Douglas Crockford wrote that it was considered, but I'm confused since
it looks like you haven't even seen a proposal, and didn't participate
in the discussion to exclude it.

- Rob

2008/7/16 Mark S. Miller <[EMAIL PROTECTED]>:
> On Wed, Jul 16, 2008 at 10:11 AM, Brendan Eich <[EMAIL PROTECTED]> wrote:
>>
>> And? The doc gives rationales for design decisions. What's the
>> rationale for leaving Object.extend out?
>
> If the document needs to give rationales for leaving out each thing we did
> not include, it would be quite a long document. What is the argument for
> adding Object.extend()? A pointer to Resig's message or a prior discussion
> is an adequate response.
>
> --
> Cheers,
> --MarkM
> ___
> Es3.x-discuss mailing list
> [EMAIL PROTECTED]
> https://mail.mozilla.org/listinfo/es3.x-discuss
>



--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."
___
Es3.x-discuss mailing list
[EMAIL PROTECTED]
https://mail.mozilla.org/listinfo/es3.x-discuss

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

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

The ES3 spec already specifies the specific prototype of each built-in object 
and their instances. However, when it comes to implementing built-in objects or 
for that matter user defined objects there is nothing that prevents an 
implementation from using "invisible" intermediate prototypes for whatever  
purposes it finds useful.  Those, of course, would not be visible to a 
getPrototypeOf function.

Penetrating an implementation encapsulation barrier whether at the "engine", 
library, or framework level always carries with it the risk of introducing 
implementation dependencies. That doesn't mean there aren't good reasons for 
doing so, you just better know what you're doing and use appropriate care.   
The static Object methods are intend for use by people who know what they are 
doing. Certainly, there is an attractive nuisance factor that will get some 
people into trouble.  If you file off all the points and dull all the edges you 
usually do end up with a very useful tool.

-Original Message-
From: Waldemar Horwat [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 2:05 PM
To: Allen Wirfs-Brock
Cc: Douglas Crockford; Brendan Eich; [EMAIL PROTECTED]; es4-discuss@mozilla.org
Subject: Re: ES3.1 Object static methods rationale document

Allen Wirfs-Brock wrote:
> In summary, not providing reflective access to an object's prototype doesn't 
> really provide any real security, it just makes some useful tasks less 
> convenient.  Reverting to barnyard analogies: the barn door is already wide 
> open and we're debating an inch wide "trench" that spans the opening.  If we 
> want to keep the horses in we need to think about how to put an iron gate 
> across that gap rather than worrying about the risks of filling in the trench.

On the other hand, providing reflective access to an object's prototype is 
harmful to compatibility because it prevents implementations from introducing 
intermediate prototypes without breaking the web.  Consider the example of 
having just Numbers and later compatibly introducing more specific subkinds of 
Numbers.

Waldemar

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

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

-Original Message-
From: Brendan Eich [mailto:[EMAIL PROTECTED]

But you raise a good
point: defineProperty creates an own property. Is there really a need
for getProperty as drafted? If not, I'd favor making describeProperty
return null if the named property is not "own", but in a prototype.

What are use-cases for getProperty as distinct from getOwnProperty?
-

For awhile, defineProperty was called defineOwnProperty but we eventually 
decided all properties are initially defined as own properties so the "Own" was 
redundant.

Right now, the best I can come up with is that it should be a relatively 
efficient way to test for the existence of a possibly inherited property. 
However, if that was really important it would probably be better to have a 
built-in function that specifically performed that test without creating a 
descriptor. We may have discussed some more compelling use cases that I don't 
now recall, in which case I'm sure someone will remind me.

In generally, I favor proving just the minimal "spanning set" of functions that 
can be used to build more comprehensive reflection models if desired. If there 
isn't a stronger use case for the version that considers inherited methods I'd 
be happy to eliminate it.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

(I'm not going to get you to take the bait on "reify", am I?)

I think I like "describe" better than "inspect" for no particularly tangible 
reason, although it does have more characters. I generally find the Thesaurus a 
useful tool in this process and it turned up "depict" which is shorter but also 
seems to capture the same core distinction as "describe".

I think that the currently named getOwnProperty is more fundamental than 
getProperty so in considering length we should probably use the former as our 
benchmark. BTW, I'm open to arguments that we don't really need getProperty (as 
long as getPrototypeOf is kept). (Oh shit ... do we need to rename that one, 
too??)

I think we've pretty much covered the "name space" and would be content, at 
this point, to sit back for a few days and see if anybody else is brave enough 
to argue for one name over another. If not I think we can reach agreement on 
one of these that we have been discussing.

Allen

-Original Message-
From: Brendan Eich [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 11:52 AM
To: Allen Wirfs-Brock
Cc: [EMAIL PROTECTED] x-discuss; es4-discuss@mozilla.org es4-discuss
Subject: Re: ES3.1 Object static methods rationale document

On Jul 16, 2008, at 11:44 AM, Brendan Eich wrote:

> On Jul 16, 2008, at 11:35 AM, Allen Wirfs-Brock wrote:
>
>> I could live with lookup, although I think it focuses the meaning
>> on the access process rather than on the result. Another, slightly
>> longer alternative would be "retrieve".
>
> What do you say to Ingvar's suggestion of "inspect"?

Or (drum roll) "describe": describeProperty, which returns a property
descriptor.

/be


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

RE: A read/write __proto__ that can vanish

[Allen Wirfs-Brock]

Personally, I don't that the internal [[Prototype]] "property" should reify as 
an actual property of the object.  It's really a more fundamental aspect of 
"objectness" than regular properties.  From that perspective, if you want to 
control access to it, it should probably be done as a flag on the object 
itself, much as the ES3.1 proposal does with the [[Extensible]] property.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ingvar von 
Schoultz
Sent: Wednesday, July 16, 2008 10:29 AM
To: [EMAIL PROTECTED]; es4-discuss@mozilla.org
Subject: A read/write __proto__ that can vanish

Some people yearn hotly for __proto__, preferrably writable if
at all possible, while others point to problems with security
and software privacy.

I get the impression that this could be solved by adding a fourth
flag among the property flags Enumerable, Writable and Flexible.
There might be a flag called Visible, so you could make __proto__
apparently vanish by setting Visible to false.

As an added bonus, this solution would let code hide the prototype
property on constructors if desired.

Personally I'd love to see it defined in such a way that I could
set prototype inheritance in a simple, straightforward way at the
beginning of a constructor function:

 function $MyConstructor()
 {  this.proto = MySuperInstance;
 // Here you can hide proto if desired.
 ...
 }

If a visible proto is standardized, the name should be proto, not
__proto__, in my opinion. The underscores indicate nonstandard.

--
Ingvar von Schoultz

--- (My quirky use of capitals in code comes from my opinion that
reserved and predefined words should all start with lowercase, and
user-defined should all start with uppercase, because this will easily
and elegantly prevent a host of name-collision problems when things
like programming languages are upgraded with new labels.)
___
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: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

I actually don't expect "mere mortal" ECMAScript programmers to be confused 
with [[get]] as I won't expect them to have ever been exposed to it.  Scanning 
the rest of the standard ECMAScript objects, the only methods that use a "get" 
prefix seem to be in Date so this may be some potential for a confusion of 
conventions there but on the other hand Date seems to largely a world onto 
itself so I don't know if its usage should really be a concern.  A bigger issue 
may be conventions that have been adopted by the more popular AJAX frameworks, 
if they are in conflict with the getProperty usage. I admit I'm not real 
familiar with the detailed APIs of the frameworks but I'm sure somebody here 
can enlighten me.

Another alternative to "get" would be "reify", eg reifyProperty.  My immediate 
reaction is that it would not be very approachable for unsophisticated users 
(in other words, most of them). On the other hand, I could argue that if you 
don't understand what reify means in this context you shouldn't be using the 
function. And, this is one of the rare case where the dictionary definition 
fairly precisely corresponds to the technical meaning. This one actually kind 
of grows on me, but I don't think I could really champion it unless there as a 
spontaneous outburst of support for it.

I could live with lookup, although I think it focuses the meaning on the access 
process rather than on the result. Another, slightly longer alternative would 
be "retrieve".

Regarding, what getOwnProperty returns, what you currently see in the spec. is 
probably a bug. My intent was for it to return undefined, although somebody 
more steeped in JavaScript idioms could convince me that null is more 
appropriate if that really is the case. The internal function 
FromPropertyDescriptor probably also needs to return that same value under the 
appropriate circumstances. Finally, here's another bug: step 3 of 
Object.getProperty should call [[GetProperty]] rather than [[GetOwnProperty]].  
Also step 4 has a "]]" that should be there.


-Original Message-----
From: Brendan Eich [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 12:37 AM
To: Allen Wirfs-Brock
Cc: [EMAIL PROTECTED] x-discuss; es4-discuss@mozilla.org es4-discuss
Subject: Re: ES3.1 Object static methods rationale document

On Jul 16, 2008, at 12:09 AM, Brendan Eich wrote:

> On Jul 15, 2008, at 11:50 PM, Brendan Eich wrote:
>
>> * getProperty and getProperties seem misnamed in light of common
>> usage of "get", "[[Get]]", "getProperty", etc. all connoting value-
>> getting, not descriptor-getting. getPropertyDescriptor is a bit
>> long, but not fatally so. Worth renaming?
>
> Shorter alternative verbs to "get": lookup, query. The analogy is
> lookup : define :: get : put.

That was unclear, sorry. I meant to suggest that "lookupProperty" is
a shorter alternative to "getPropertyDescriptor". Using "lookup" or
"query" relieves the need for "Descriptor" at the end to disambiguate
value- from descriptor-getting. So:

// returns descriptor if (name in obj), else null or something falsy [1]
Object.lookupProperty(obj, name)

It's still longer than Object.getProperty, but Object.getProperty
seems like a misnomer every time I read it, since it does not do a
[[Get]] or [[GetProperty]]. ECMA-262 does not need more overloadings
of "get-property" names.

Similar comments apply to Object.getOwnProperty.

/be

[1] The 15 July 2008 draft specifies false, not null, as the return
value of Object.getProperty(O, P) when !(P in O) -- is this intended?

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

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

I didn't specifically respond to that thread because I wasn't aware of it.  I 
had intended to mention __proto__ as a precedent but it slipped through the 
cracks.

It's true that __proto__ or getPrototypeOf breaks an object's encapsulation 
barrier and reveals implementation details that perhaps were intended to be 
hidden.  The same could be said about the proposed getProperty function which, 
among other things,  gives an observer access to the functions that implement a 
getter/setter property. In general, that's the nature of reflection. Overall, I 
think that this is a situation that is inherent in our current generation of 
dynamic languages. They tend to depend upon the use of idioms that require 
penetration of the encapsulation barrier.

Some of the concerns expressed in that thread are address by other aspects of 
the static Object methods proposal.  For example, the integrity of prototype 
objects can be protected by sealing them in whole or in part to prevent 
tampering. Also note, that while we support inspection of the prototype value, 
we don't support modification of it.

As Doug implies below, one reason for making these operations "static methods" 
was to make it easier to control access to them.  It you are creating some sort 
of sandbox, you may not want to make them available within it.  That could be 
taken as a argument in favor of hanging them off of a dedicated global Meta 
object rather than off of Object.  It may be slightly easier to wholesale 
restrict access to Meta than it would be to restrict access to just these 
methods while still providing access to the Object constructor.

Another already available technique for obtaining the same information in many 
situations that wasn't mentioned in the thread is to use 
Object.prototype.isPropertyOf as a probe to discover the prototypes of objects. 
It isn't something that you would want to do in production code but I don't 
think that anyone who was trying to crack an application would hesitate from 
doing.

Arguably, some of the need for direct prototype access is alleviated by 
providing the clone method.  However, there are still plenty of other 
situations where it is useful.

I don't agree with Lars' contention that __proto__ and function.caller present 
the same kind of problem. True, they both break abstraction barriers, but 
different  barriers.  __proto__ breaks the object implementation abstraction 
layer.  Function.caller breaks the call stack abstraction. Crossing the object 
implementation boundary is generally required for defining object abstractions 
in this language and __proto__ only reveals information that in most cases is 
already available through other, less direct, means. In contrast, 
function.caller reveals information about the call stack that is not normally 
reified in this language or generally needed (those who consider continuations 
the ultimate programming abstraction may disagree).

In summary, not providing reflective access to an object's prototype doesn't 
really provide any real security, it just makes some useful tasks less 
convenient.  Reverting to barnyard analogies: the barn door is already wide 
open and we're debating an inch wide "trench" that spans the opening.  If we 
want to keep the horses in we need to think about how to put an iron gate 
across that gap rather than worrying about the risks of filling in the trench.

Allen

-Original Message-
From: Douglas Crockford [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 5:39 AM
To: Brendan Eich
Cc: Allen Wirfs-Brock; [EMAIL PROTECTED]; es4-discuss@mozilla.org
Subject: Re: ES3.1 Object static methods rationale document

Brendan Eich wrote:
> * No rationale responding to the thread containing this message:
>
> https://mail.mozilla.org/pipermail/es4-discuss/2007-September/001114.html
>
> that questions the wisdom of getPrototypeOf. The other rationales are
> helpful, the lack of one responding to this public thread questioning
> essentially the same design element is a lack -- what do you think?

The motivation for these methods is to allow Ajax libraries and the Caja runtime
to harden the environment. Such a library can use and them remove these methods,
disallowing access by guest code.

> * Did you consider prototype's Object.extend method:
>
> Object.extend = function(destination, source) {
>   for (var property in source)
> destination[property] = source[property];
>   return destination;
> };

Yes we did.

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

ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

I've up loaded to the wiki a new document titled:  "Proposed ECMAScript 3.1 
Static Object Functions: Use Cases and Rationale"

It's available as both a pdf and as a Word doc file:
http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.1_proposal_working_draft&cache=cache&media=es3.1:rationale_for_es3_1_static_object_methods.pdf
http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.1_proposal_working_draft&cache=cache&media=es3.1:rationale_for_es3_1_static_object_methods.doc
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: Two interoperable implementations rule

[Allen Wirfs-Brock]

A few thoughts on the general topic and various points that are been raised:

Overall, I think this is a good idea.  My personal opinion is that 
standardization should follow proven utility, not the other way around.  
However, it's difficult to get meaningful use of proposed web standards until 
there is ubiquitous implementation. If we, as a community, can find a way to 
meaningfully work together to advance web technology it will be a very good 
thing.

Realistically, I think it has to be real browser-based implementations. 
However, Maciej's at least one browser implementation suggestion may be good 
enough. My perception is that we have far more unresolved "will it break the 
web" arguments then we do about the actual utility of features.  Let's just 
demonstrate it on the web, one way or another.  BTW, I think this puts us 
(Microsoft) at a disadvantage because we have self imposed restrictions that 
currently make it much harder for us to publicly demonstrate (or even discuss) 
browser changes or enhances than it would be for any sort of standalone 
implementation we did. We'll have to learn how to deal with it.

Conversely, I don't think a "reference implementation" really makes the cut, 
even if it is hosted in a browser.  However, there isn't necessarily a sharp 
line between a reference implementation and a simplistic or naïve "production" 
implementation so maybe the browser hosted requirement is as close as we can 
come to pinning that down.

I'm ambivalent on the single feature or entire specification question. For a 
spec. on the order what is being proposed as ES3.1 I don't think an entire 
spec. requirement would be unreasonably burdensome.  For more complex feature 
sets I'm less sure.  A related question is what does it take for a feature to 
even get into a proposed specification? You can't require complete 
implementation of a spec. that is not yet complete.  Is a public, browser based 
implementation a pre-requisite for even getting to the state of a feature 
proposal? I could argue both sides of that one.

Feature interactions are often a source of unanticipated problems.  That argues 
for testing an entire specification.

Is there a time limit in which implementations must occur?  How do we actually 
reach the point of "shipping" a revised specification.

An implementation, without some way to validate it seems of limited use.  
Should we also expect those who propose features to also provide a validation 
suite?

How fine a granularity do we push this to. Some of the sorts of clarify changes 
to existing specification language or changes to specification models that are 
needed to accommodate new features may not even be directly testable if their 
intent is no net change to the existing feature set.

Don't take this a "vote" yet, as we certainly need to have some internal 
discussion on the topic.  However, I don't see how such a requirement would be 
in any way inconsistent with how Microsoft currently thinks about the process 
of web evolution.

Allen

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

RE: Update on ES3.1 block scoped function declarations

[Allen Wirfs-Brock]

I see, yes there is a potential eval tax.  If I thought this was really a 
concern (and as you say, we already have the issue for catch and such) I'd be 
more inclined to fiddling with the scoping rule of eval rather than discarding 
lexically scoped consts.  BTW, I think many of the use cases for such const are 
more in support of code generators then actual end user programming.


From: Brendan Eich [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 10, 2008 2:03 PM
To: Allen Wirfs-Brock
Cc: Mark S. Miller; [EMAIL PROTECTED]; es4-discuss@mozilla.org; Herman Venter
Subject: Re: Update on ES3.1 block scoped function declarations

On Jul 10, 2008, at 1:58 PM, Allen Wirfs-Brock wrote:
Maybe, I'm missing something subtle, but 21 is clearly the right answer and is 
what I believe is specified by the version of section 10 that I sent out 
yesterday regardless of the scoping of block nested functions.  Of course, 
that's just spec-ware...

21 is the right answer, I agree. But it requires reifying what could otherwise 
be lexical bindings the compiler tracks and then throws away, just so the 
compiler invoked by eval can see the bindings again. It's true that catch 
variables also need this kind of infrastructure, and named function 
expressions. So you could argue "in for a penny, ...". But block-scoped const 
in ES3.1, without let or function, is kind of half-a-pound, if you get my 
meaning. All the implementation cost, half the utility.

/be


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brendan Eich
Sent: Thursday, July 10, 2008 1:45 PM
To: Mark S. Miller
Cc: [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>; 
es4-discuss@mozilla.org<mailto:es4-discuss@mozilla.org>; Herman Venter
Subject: Re: Update on ES3.1 block scoped function declarations

On Jul 10, 2008, at 1:28 PM, Mark S. Miller wrote:



On Thu, Jul 10, 2008 at 11:05 AM, Brendan Eich <[EMAIL PROTECTED]<mailto:[EMAIL 
PROTECTED]>> wrote:

So what would this program print in ES3.1?

const C = 42;
function f(x, y) {
  const C = 33;
  if (x) {
const C = 21;
return eval(y);
  }
  return C;
}
print(f(true, "C"));

21

What does it print in ES4-opt-in?

Call it ES4, please. There's no point in playing games about opt-in, since we 
know we can't "break the web". ES3 added new syntax, so did ES2. No one bugged 
out about "opt-in".

21 is the right answer, although reflecting lexical blocks into something eval 
can see is a big pain (we did this in Firefox 2). It's a lot of work just for 
block-scoped const. Sorry if I missed the discussion, but was restricting const 
to top level considered?

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org<mailto: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: Update on ES3.1 block scoped function declarations

[Allen Wirfs-Brock]

Maybe, I'm missing something subtle, but 21 is clearly the right answer and is 
what I believe is specified by the version of section 10 that I sent out 
yesterday regardless of the scoping of block nested functions.  Of course, 
that's just spec-ware...

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brendan Eich
Sent: Thursday, July 10, 2008 1:45 PM
To: Mark S. Miller
Cc: [EMAIL PROTECTED]; es4-discuss@mozilla.org; Herman Venter
Subject: Re: Update on ES3.1 block scoped function declarations

On Jul 10, 2008, at 1:28 PM, Mark S. Miller wrote:


On Thu, Jul 10, 2008 at 11:05 AM, Brendan Eich <[EMAIL PROTECTED]> wrote:

So what would this program print in ES3.1?

const C = 42;
function f(x, y) {
  const C = 33;
  if (x) {
const C = 21;
return eval(y);
  }
  return C;
}
print(f(true, "C"));

21

What does it print in ES4-opt-in?

Call it ES4, please. There's no point in playing games about opt-in, since we 
know we can't "break the web". ES3 added new syntax, so did ES2. No one bugged 
out about "opt-in".

21 is the right answer, although reflecting lexical blocks into something eval 
can see is a big pain (we did this in Firefox 2). It's a lot of work just for 
block-scoped const. Sorry if I missed the discussion, but was restricting const 
to top level considered?

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

Update on ES3.1 block scoped function declarations

[Allen Wirfs-Brock]

We discussed these issues at today's ES3.1 conference call and arrived at a new 
plan of record:

1) We concluded that the present diversity of semantics of block nested 
function declarations among browser implementations probably cannot be replaced 
with a standard semantics without significant breakage of the web. One 
compelling use case is the apparent common usage of the difference in IE and FF 
semantics  in this regard as a browser identification test. So, for ES3.1 we 
will not change the ES3 stance on such function declarations. This means, that 
block nested functions will not be part of the ES3.1 syntax or semantics.  The 
occurrence and meaning of them in an implementation dependent non-standard 
language extension that is  allowable by section 16.  Our expectation is that 
most implementations will just continuing doing what they currently do.

2) While we can't reconcile the divergent existing semantics of function 
declarations within blocks, we can discourage  their on-going use.  To that 
end, the cautious subset will specify that the occurrence of such a function 
declaration must be reported as a syntax error at scan time. So, while section 
16 of the full ES3.1 language implicitly permits implementations to allow  
block nested function declarations, the opt-in cautious subset explicitly 
withdraws that permission.

3) We will still include lexically scoped block environments, but only for 
const declarations. If you want to define a block scoped function, do it using 
a const whose value is a function expression.  In a latter revision, we would 
expect to also add block-scoped let declaration to enable block scoped 
variables.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: Newly revised Section 10 for ES3.1.

[Allen Wirfs-Brock]

This is currently stated in section 4.2.2 of the draft as:


With one exception, an ECMAScript program that is voluntarily limited to a 
usage subset  and which executes without error under the subset's restrictions 
will behave identically if executed without on any usage subset restrictions. 
The exception is any situation where the operation of such a program depends 
upon the actual occurrence and subsequent handling of additional error 
conditions that are part of the subset.


From: Mark S. Miller [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2008 10:48 PM
To: Allen Wirfs-Brock
Cc: Garrett Smith; es4-discuss@mozilla.org; Herman Venter; Pratap Lakshman 
(VJ#SDK); Douglas Crockford
Subject: Re: Newly revised Section 10 for ES3.1.

On Wed, Jul 9, 2008 at 10:35 PM, Allen Wirfs-Brock <[EMAIL 
PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote:
Every valid proposed ES3.1 cautious subset program is also a valid program in 
the full language.

I don't think it works to restate the "fail stop subset" notion in terms of 
validity. Rather, we can say that an ES3.1 cautious program that runs without 
causing any cautiousness-induced failures will run the same way in the full 
language. Put another way, Given an alleged ES3.1 cautious program, it will

* be statically rejected
* cause a failure by violating a dynamic cautiousness restriction
* execute as it would in the full ES3.1 language.

For example, the following is a perfectly *valid* ES3.1 cautious function:

function isCautious() {
  function foo() {this;}
  try { foo(); } catch (e) { return true; }
  return false;
}

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

RE: Newly revised Section 10 for ES3.1.

[Allen Wirfs-Brock]

>> It seems like that would be at least as much worth trying as is "make
something that's actively incompatible with all 4 browsers", no?

I'd love to see a proposal

>> I can only presume that you're joking here.

Not really, if you have to change something it may be better to do it in a way 
that breaks all existing uses rather than just some of them.  It isn't obvious 
that either the FF or IE approach to function declarations in conditional 
blocks is "better" or more correct.  Arguments can be made on both design 
choices. In such a situation, the best solution may actually be to break both 
of them rather than breaking only one of them.  Particularly, if there is a 
strong argument that the new design is better than either of the existing ones.

>> FWIW, this sort of thing is a reason that I'm pretty concerned about
ES3.1 getting into an advanced specification state without the benefit
of any in-browser implementation.

You need to have an advance specification state before you can meaningfully 
test it in an implementation.

-Original Message-
From: Mike Shaver [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2008 9:49 PM
To: Allen Wirfs-Brock
Cc: Maciej Stachowiak; Herman Venter; Mark S. Miller; [EMAIL PROTECTED]; 
es4-discuss@mozilla.org
Subject: Re: Newly revised Section 10 for ES3.1.

2008/7/10 Allen Wirfs-Brock <[EMAIL PROTECTED]>:
> Even if we can craft a
> specification that just captured those aspects of block nest function
> declarations that are identical in the 4 principal browsers would It's not
> clear that anybody would  be very happy with the result.

It seems like that would be at least as much worth trying as is "make
something that's actively incompatible with all 4 browsers", no?

> Arguably, one "advantage" of my proposal is that it equally breaks
> all the existing implementations of block nested function declarations.

I can only presume that you're joking here.

FWIW, this sort of thing is a reason that I'm pretty concerned about
ES3.1 getting into an advanced specification state without the benefit
of any in-browser implementation.

Mike

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

RE: Newly revised Section 10 for ES3.1.

[Allen Wirfs-Brock]

There was two parts to may message, an informal overview of the proposed 
semantics and the excerpt from the actual "formal" (and I use that term 
advisedly) specification of the semantics.  I was using the term "top-level" in 
the informal part of the message to refer to code that wasn't in a nested 
block.  It is not intended to be new formal terminology of the specification.  
It has nothing to do with the [[Scope]] property.  I do introduce some new 
formal terminology but it is all in the specification excerpt, not in the 
informal overview.  [[Scope]] is simply the internal property that is used to 
capture the lexical environment (the scope chain) that is active when a 
function object is created.

What I do introduce is a new kind of execution context for lexical blocks and a 
new kind of activation object that is associated with lexical block execution 
contexts.

You confusion about the meaning of my informal language reasonably points out 
the weakness of informal descriptions. Please read the actual rewrite of 
section 10 and see if you also find it confusing or ambiguous. If so, that's 
important and something I will try to fix.

Regarding, the "cautious subset" restrictions.  By design, they are 
incompatible with ES3.  The cautious subset (or the similar but not yet 
identical ES4 strict mode" is an Opt-in subset of the ES3.1 language that among 
other things allows a programmer to request that certain problematic ES3 
constructs become illegal and generate errors. Every valid proposed ES3.1 
cautious subset program is also a valid program in the full language.  However, 
every valid program in the full language is not necessarily a valid cautious 
subset program.

-Original Message-
From: Garrett Smith [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2008 6:48 PM
To: Allen Wirfs-Brock
Cc: es4-discuss@mozilla.org; Mark S. Miller; Herman Venter; Pratap Lakshman 
(VJ#SDK); Douglas Crockford
Subject: Re: Newly revised Section 10 for ES3.1.

2008/7/9 Allen Wirfs-Brock <[EMAIL PROTECTED]>:
> I've just finished reworking section 10 to better accommodate block scoped
> function declarations and const statements.  In the course of this I had to
> make various decisions about the semantics. The primary purpose of this
> message is to provide visibility to those decisions and to get feedback on
> them.
>
>
>
> In introducing const statements and block scoped function declaration I
> tried to apply two over-riding principles:
>
> 1) Anything that is valid to do in ES3 continues to have the exact same
> semantics.
>
> 2) Anything thing that is new (or non-standard) and would not be valid in
> ES3 should have a semantics that is rational and consistent with a future
> introduction of block scoped Let variable bindings
>
>

A FunctionDeclaration in a block is not valid in ES3, so apparently
that is the reason for your note.

>
> Here are the results:
>
> All var declarations continue to be hoisted to "top-level" execution
> context. Vars never have block level scope or extent.
>
> ("top-level" mean the global code, eval code, or the top-level of a
> function.
>

This sentence is confusing. eval code is not necessarily global.

Reading further down, it seems that you mean to define "top-level" as
a new term for what we already know to mean [[Scope]] and then to
define a block scope term. It seems that you are aiming to
differentiate between function scope and a new type of "block" scope.

If my assumption is correct, then creating a new type of "block" scope
does not necessitate changing the term [[Scope]] to "top level".
[[Scope]] can still be [[Scope]] and block scope can be called
whatever you like ([[Block]], [[BlockScope]], et c)

Does this sound reasonable?

>
>
> Function declarations and const declarations are processed in parallel
> within a lexical contour (top-level or block). Neither has precedence over
>  the other, unlike the manner in which function declarations take precedence
> over formal parameters in ES3.
>
>
>
> A "top-level" function declaration over-writes any like-named formal
> parameters or preceding like-named function declarations.  This is an ES3
> semantics.
>

The global object cannot have parameters, so I should probably assume
that top-level means the same thing as [[Scope]] in ES3.

When you use a made-up word like "over-writes" it is unclear. It could
mean any of:

1) replaces the value
2) replaces the value and attributes
3) shadows a property in the scope chain (some do use the term
"override" in this way)

It is not clear what you mean.

> "Top-level" function declarations are writable.  Subsequent declarations or
> assignments may change their value. This is an ES3 semantic

RE: Newly revised Section 10 for ES3.1.

[Allen Wirfs-Brock]

I'm also confused about this.  My understanding was, other than perhaps some of 
the details I was specifically looking for feedback on, that what I specified 
was generally what ES4 was planning on doing.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark S. Miller
Sent: Wednesday, July 09, 2008 7:13 PM
To: Brendan Eich
Cc: Herman Venter; Douglas Crockford; [EMAIL PROTECTED]; 
es4-discuss@mozilla.org; Pratap Lakshman (VJ#SDK)
Subject: Re: Newly revised Section 10 for ES3.1.

On Wed, Jul 9, 2008 at 7:02 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
On Jul 9, 2008, at 6:58 PM, Mark S. Miller wrote:
Hi Maciej, IIUC, these examples work the same in Allen's proposal as the do in 
ES4. If this does break the web, doesn't ES4 have exactly the same problem?

The idea for ES4 was to change the meaning of function sub-statements only 
under opt-in versioning. Implementations would do whatever they do today 
without an explicit type="application/ecmascript;version=4" or equivalent 
"application/javascript;version=2" on the script tag.


I had not understood that. I knew that new keywords were switched by the ES4 
opt-in, and I have been following what ES4 switches based on strictness, but I 
probably haven't paid enough attention to ES4 opt-in. Besides keywords, what 
other elements of ES4 are switched on opt-in rather than strictness? Are all 
four combinations of opt-in vs strictness possible? Is opt-in per execution 
context (script) or per global object (frame)? A link to the relevant docs is 
an adequate answer. Thanks.


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

RE: Newly revised Section 10 for ES3.1.

[Allen Wirfs-Brock]

I completely agree, chapter 16 needs to carry forward.  We don't want to forbid 
implementations from experimenting with future extensions.

When there has been broad agreement across major implements on an extension 
(including the full semantics), I think it makes sense to standardize that 
consensus. If there isn't such agreement, I'm not so sure it makes sense to 
only standardize the compatible intersection of major implementations as that 
may not be a useful subset of functionality.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brendan Eich
Sent: Wednesday, July 09, 2008 7:00 PM
To: Mark S. Miller
Cc: [EMAIL PROTECTED]; es4-discuss@mozilla.org; Herman Venter
Subject: Re: Newly revised Section 10 for ES3.1.

On Jul 9, 2008, at 6:54 PM, Mark S. Miller wrote:

> On Wed, Jul 9, 2008 at 6:47 PM, Mike Shaver <[EMAIL PROTECTED]>
> wrote:
> 2008/7/9 Maciej Stachowiak <[EMAIL PROTECTED]>:
> > > Although the standard does not allow block-level function
> declarations
>
> > I'd understood that, while ES3 didn't specify such declarations, it
> > was not a violation of the standard to have them.  I agree with your
> > assessment of the compatibility impact, certainly.
>
> I believe the prohibition is in the ES3 syntax definition.

ES3 chapter 16:

An implementation shall report all errors as specified, except for
the following:
* An implementation may extend program and regular expression syntax.
To permit this, all operations (such as
calling eval, using a regular expression literal, or using the
Function or RegExp constructor) that are allowed
to throw SyntaxError are permitted to exhibit implementation-defined
behaviour instead of throwing SyntaxError
when they encounter an implementation-defined extension to the
program or regular expression syntax.

As Maciej notes, all four browsers extend syntax to support functions
in sub-statement contexts. There's no prohibition given the chapter
16 language allowing such extensions. Is ES3.1 specifying
"reality" (intersection semantics), or something not in the
intersection or union of existing browsers' syntax and semantics,
that is restrictive and therefore not compatible without a similar
allowance for extensions?

Chapter 16 is important to carry forward in any 3.1 or 4 successor
edition.

/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

RE: Newly revised Section 10 for ES3.1.

[Allen Wirfs-Brock]

Yes, but

function g() {
if (true) {
function f() { alert("1"); }
   }
   Else {
function f() { alert("2"); }
}
f();
}
g();


doesn't yield consistent results across browsers. Even if we can craft a 
specification that just captured those aspects of block nest function 
declarations that are identical in the 4 principal browsers would It's not 
clear that anybody would  be very happy with the result. (For example, a 
function of a given name can occurs in at most one conditionally executed 
block). Arguably, one "advantage" of my proposal is that it equally breaks all 
the existing implementations of block nested function declarations.

From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2008 6:34 PM
To: Allen Wirfs-Brock
Cc: [EMAIL PROTECTED]; es4-discuss@mozilla.org; Mark S. Miller; Herman Venter; 
Pratap Lakshman (VJ#SDK); Douglas Crockford
Subject: Re: Newly revised Section 10 for ES3.1.


On Jul 9, 2008, at 5:16 PM, Allen Wirfs-Brock wrote:



Const and function declarations within blocks must be uniquely named, such a 
declaration may not over-write a preceding declaration in the same block and an 
attempt to do so is a syntax error.  Such declarations, of course, shadow any 
like named declarations in enclosing scopes. Since consts and function 
declarations in blocks are new, this is a new semantics.

Although the standard does not allow block-level function declarations, the 
following will parse and give identical results in all four of the major 
browsers (it will alert "2"):


function g() {
if (true) {
function f() { alert("1"); }
function f() { alert("2"); }
}
f();
}
g();


This example will interoperably alert "1":


function g() {
if (true) {
function f() { alert("1"); }
}
f();
}
g();


As I understand it, your proposal would make the first example a syntax error 
and the second a runtime error (unless a global function named f is defined).

I know from experience that sites do accidentally depend on the intersection of 
the different IE and Firefox extensions for block-level function declarations 
(and the Safari and Opera attempts to emulate them). Do you have evidence that 
leads you to conclude that your proposed behavior is compatible with the Web? I 
am almost certain it is not.


Regards,
Maciej

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

RE: for-in statement: null and undefined

[Allen Wirfs-Brock]

We'll look into it for ES3.1.  It sounds like it's something we've overlook 
that meets our criteria for changes that reflect web reality. It's possible we 
might want to leave the exception in for our cautious (ie strict) subset.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kent Hansen
Sent: Thursday, July 03, 2008 8:43 AM
To: [EMAIL PROTECTED]; es4-discuss@mozilla.org
Subject: for-in statement: null and undefined

Hi,
In the current public ES4 reference implementation [1], iterating over
null and undefined is a no-op instead of a TypeError, which is in line
with the proposal at [2] (which points out that existing web browsers
already do this). However, the most recent ES3.1 draft [3] does not
incorporate this change. It's not mentioned in Douglas Crockford's
recommendations for modifications to ES [4] either, nor in the proposed
incompatibilities [5]. So my question is, will this change be part of
ES3.1 or not (doesn't it have to, for ES4 compatibility's sake)? I can't
find a discussion of this issue anywhere.

By the way, in the ES4 reference implementation, iterating over strings
is a no-op as well; implementation bug, or are string properties not
enumerable in ES4? "X".hasOwnProperty(0) returns false, too.

Regards,
Kent

[1]
http://www.ecmascript.org/license.php?file=es4-pre-release.M2.linux-x86.tar.gz
[2] http://wiki.ecmascript.org/doku.php?id=proposals:bug_fixes
[3]
http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.1_proposal_working_draft&cache=cache&media=es3.1:tc39-es31-draft02jul08.pdf
[4] http://www.crockford.com/javascript/recommend.html
[5] http://www.ecmascript.org/es4/spec/incompatibilities.pdf
___
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

early reporting of malformed regex literals

[Allen Wirfs-Brock]

In your comments on the June 11, ES3.1 draft you said:


p22 7.8.  Unacceptable change: The requirement to signal regular

expression syntax errors at scanning time breaks existing programs.

(The justification ("since the arguments are the same every tine[sic],

..." appears to have no bearing on that and should be removed in any

case.)

If the existing browser implementations don't do this, would you agree it would 
be better to simply eliminate the scanning time option?

Presumably, it would be acceptable to require early report in an opt-in "strict 
mode"
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: ES3.1 Draft: 24 June 2008 version available

[Allen Wirfs-Brock]

So far, we've been trying to primarily track changes relative to the original 
ES3 spec. and that is how we intend to release next week's version.  However, 
we can probably create you a version that shows the delta's relative to the 
June 11 version if that would be helpful.  I think after next week's release 
will probably be the right point to start trying to maintain a change log.

I wouldn't recommend putting much energy into the June 24 version as that is 
just a working draft that is not very clean or complete.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen
Sent: Thursday, June 26, 2008 9:18 PM
To: Pratap Lakshman (VJ#SDK); [EMAIL PROTECTED]
Cc: es4-discuss@mozilla.org
Subject: RE: ES3.1 Draft: 24 June 2008 version available

Is there a changelog between successive ES3.1 drafts?

--lars

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pratap Lakshman 
(VJ#SDK)
Sent: 26. juni 2008 22:23
To: [EMAIL PROTECTED]
Cc: es4-discuss@mozilla.org
Subject: ES3.1 Draft: 24 June 2008 version available

I have uploaded to the wiki 
(link,
 see under "Draft Specification") the current draft of the specification for 
ES3.1. This is in the form of in-place edits and markups to the ES3 
specification (specifically, on the 11 June draft). Revision history is at the 
end of the document.

I have not yet incorporated the review comments you sent on the 11 June draft. 
For the moment I am focusing on incorporating normative content, but will 
certainly address all of your review comments in upcoming drafts.

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

RE: "strict mode" becomes "use subset cautious"

[Allen Wirfs-Brock]

I  believe that identification of such a list  is something that we (ES3.1 and 
ES4) are going to have to work on together.  Getting the 3.1 draft. largely 
complete should be an enabler to get that started.  Resolution is also a two 
way street that is also going to require joint work.

We're working to get a technically complete draft out by the middle of next 
week so people can start reviewing it in preparation for Oslo.  There is a fair 
chance that we won't get the "formal" specification work done for a couple for 
features by then.  If that proves to be the case we intend to include a summary 
description of the missing features and then follow that up with spec. 
supplements covering those features as quickly as we can.

From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 26, 2008 4:33 PM
To: Allen Wirfs-Brock
Cc: [EMAIL PROTECTED] x-discuss; es4-discuss@mozilla.org es4-discuss
Subject: Re: "strict mode" becomes "use subset cautious"


On Jun 26, 2008, at 1:34 PM, Allen Wirfs-Brock wrote:


At today's ES 3.1 conference call (see 
http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jun_24_2008) we agreed 
to adopt the essence of the proposal below and to use the subset name 
"cautious" to referred to the set of restrictions formerly known as "strict 
mode"

Will ES4 also be making this change? If not, we need to add it to the list of 
subset rule violations. Is anyone keeping such a list? Does the ES3.1 committee 
intend to address all such issues by the July timeframe that ES3.1 is 
apparently targetting?

Regards,
Maciej



_
From: Allen Wirfs-Brock
Sent: Wednesday, June 25, 2008 12:38 PM
To: Pratap Lakshman (VJ#SDK); Adam Peller; Sam Ruby; Mark S. Miller
Cc: [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]> x-discuss; 
es4-discuss@mozilla.org<mailto:es4-discuss@mozilla.org> es4-discuss
Subject: RE: Brief Minutes [RE: ES3.1 WG phone conference 24 June 08:00 PT]


Following up on the "Strict Mode" discussion...

As I advocated on the call, I think that by selecting "strict mode" a developer 
is really choosing to restrict themselves to using a subset of the complete 
language.  The future-proofing issues  of this relate to the possibility that 
there might be multiple such subsets that a developer might need to choose 
among.  Should there be multiple named "strict modes" to choose among, how 
should they be named, can "strictness" of a mode increase in future versions, 
etc?

I think some of the controversy could be eliminated if we simply eliminate the 
term "Strict Mode".  Instead I propose we have a "Use Subset" directive  and 
that we name specific subsets in a meaningful and generally positive manner.  
For example,  since the motivation of most of the proposed restrictions in 
ES3.1 strict mode is to provide a safer subset language I suggest that we call 
this subset "safety"  (or perhaps "safety1" or "safetyA"  or "safety2008" 
implying that in the future different safe subsets might be defined and we 
don't want to give undo importance to this initial one).

So, the first line of a "strict mode" compilation unit would now look like"
"use subset safety"

I would suggest that we actually define "use subset" such that a comma 
separated list of subsets is allowed.  So, if somebody decided to define a 
subset that only contained the features of ES3 you might see something like 
this:
"use subset safety,ES3"

Since subsets are sets of restrictions, listing multiple subsets means to take 
the union of the restrictions imposed by all of the listed subsets.  So "use 
subset safty,ES3" means that this compilation unit may only use those features 
defined by ECMA 262-3 and which are not excluded by the "safety" subset.  So, 
assuming that "safety" excludes use of the with statement, such a compilation 
unit could not include use of the with statement nor could it include any use 
of a feature that is new in ES3.1 or ES4.

Future versions of ECMAScript may add exclusions to a subset defined by an 
earlier version as long as the added exclusions only restrict capabilities that 
didn't exist in the earlier version. For example, ES 4 in supporting the ES3.1 
"safety" subset but add to it any features that are added in ES 4  but which 
are considered to be unsafe.

A future version may not add  exclusion to an pre-existing subset that 
restricts features that existed when the original subset was defined.  For 
example if ES3.14 or ES5 decided that the for-in statement was unsafe, it could 
not add that restriction to the "safety" subset.  However, it could define a 
new subset named perhaps "safety2010" that includes all the restrictions 

RE: "dynamic" attribute nomenclature

[Allen Wirfs-Brock]

At today's ES 3.1 conference call (see 
http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jun_24_2008)  we agreed 
to use the term "Flexible" for the property attribute that we recently had been 
calling "Dynamic" and which subsumes the DontDelete attribute.

From: Allen Wirfs-Brock
Sent: Wednesday, June 25, 2008 10:37 AM
To: Lars Hansen; Mark S. Miller
Cc: [EMAIL PROTECTED] x-discuss
Subject: "dynamic" attribute nomenclature

In Lars's feedback on the the June 11, ES3.1 draft he said:

p26 8.6.1.  (And throughout the spec) The meaning of "dynamic" in ES4
is something else (it means a non-fixture property).  It would
probably reduce confusion if the property name Deletable were used
here, as I though we had agreed previously.

Dynamic as currently used in ES3.1 means more than just Deletable, it also 
means that the property attributes (including the Dynamic attribute) can be 
modified and that it can be transformed  between being a data and procedural 
property. Hence, the name Deletable seems to imply something too narrow.

Playing around with the thesaurus, the best "positive, active term that I could 
find that seems to be a reasonable description of this semantics is:
  Alterable

(other, perhaps less satisfy or otherwise unacceptable alternatives include: 
changeable, mutable, modifiable, flexible, amendable)

Note this would mean  that data properties would expose properties named 
Writable and Alterable.  My sense is that there is enough conceptual  distance 
between those terms that there won't be too much confusion.

Thoughts??

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

"strict mode" becomes "use subset cautious"

[Allen Wirfs-Brock]

At today's ES 3.1 conference call (see 
http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jun_24_2008)  we agreed 
to adopt the essence of the proposal below and to use the subset name 
"cautious" to  referred to the set of restrictions formerly known as "strict 
mode"

_________
From: Allen Wirfs-Brock
Sent: Wednesday, June 25, 2008 12:38 PM
To: Pratap Lakshman (VJ#SDK); Adam Peller; Sam Ruby; Mark S. Miller
Cc: [EMAIL PROTECTED] x-discuss; es4-discuss@mozilla.org es4-discuss
Subject: RE: Brief Minutes [RE: ES3.1 WG phone conference 24 June 08:00 PT]


Following up on the "Strict Mode" discussion...

As I advocated on the call, I think that by selecting "strict mode" a developer 
is really choosing to restrict themselves to using a subset of the complete 
language.  The future-proofing issues  of this relate to the possibility that 
there might be multiple such subsets that a developer might need to choose 
among.  Should there be multiple named "strict modes" to choose among, how 
should they be named, can "strictness" of a mode increase in future versions, 
etc?

I think some of the controversy could be eliminated if we simply eliminate the 
term "Strict Mode".  Instead I propose we have a "Use Subset" directive  and 
that we name specific subsets in a meaningful and generally positive manner.  
For example,  since the motivation of most of the proposed restrictions in 
ES3.1 strict mode is to provide a safer subset language I suggest that we call 
this subset "safety"  (or perhaps "safety1" or "safetyA"  or "safety2008" 
implying that in the future different safe subsets might be defined and we 
don't want to give undo importance to this initial one).

So, the first line of a "strict mode" compilation unit would now look like"
"use subset safety"

I would suggest that we actually define "use subset" such that a comma 
separated list of subsets is allowed.  So, if somebody decided to define a 
subset that only contained the features of ES3 you might see something like 
this:
"use subset safety,ES3"

Since subsets are sets of restrictions, listing multiple subsets means to take 
the union of the restrictions imposed by all of the listed subsets.  So "use 
subset safty,ES3" means that this compilation unit may only use those features 
defined by ECMA 262-3 and which are not excluded by the "safety" subset.  So, 
assuming that "safety" excludes use of the with statement, such a compilation 
unit could not include use of the with statement nor could it include any use 
of a feature that is new in ES3.1 or ES4.

Future versions of ECMAScript may add exclusions to a subset defined by an 
earlier version as long as the added exclusions only restrict capabilities that 
didn't exist in the earlier version. For example, ES 4 in supporting the ES3.1 
"safety" subset but add to it any features that are added in ES 4  but which 
are considered to be unsafe.

A future version may not add  exclusion to an pre-existing subset that 
restricts features that existed when the original subset was defined.  For 
example if ES3.14 or ES5 decided that the for-in statement was unsafe, it could 
not add that restriction to the "safety" subset.  However, it could define a 
new subset named perhaps "safety2010" that includes all the restrictions of the 
"safety" subset and in addition disallows use of the "for" statement.

If a compilation unit specifies a subset that is not known to the 
implementation that is processing it, that subset restriction is simply 
ignored. The code in the unit is still either valid or invalid on its own merit 
just like is the case when no subset had been specified.



_
From: Pratap Lakshman (VJ#SDK)
Sent: Tuesday, June 24, 2008 11:43 AM
To: Adam Peller; Sam Ruby; Mark S. Miller; Allen Wirfs-Brock; Pratap Lakshman 
(VJ#SDK)
Subject: Brief Minutes [RE: ES3.1 WG phone conference 24 June 08:00 PT]


Here are brief minutes from our call.
Please take a look, and let me know if you want any changes by your EOD.
I'll upload it to the wiki and send a copy to Patrick Charollais (ECMA) for 
posting on the ECMA site tomorrow night (Redmond time).

Attendees
Adam Peller (IBM)
Sam Ruby (IBM)
Mark Miller (Google)
Allen Wirfs-Brock (Microsoft)
Pratap Lakshman (Microsoft)

Agenda
On posting the latest draft to the wiki
Getters/Setters
Decimal
Setting up a review based on Lars' feedback on the 11 June draft

Minutes
Would like to add a couple more items to agenda that we can get to if we have 
the time (1) inconsistence language like "as if by the expression ..." 
pervasive in ES3 (e.g. section 11.1.4 Array Initializer: "create a ne

RE: ES 3.1 implementations?

[Allen Wirfs-Brock]

Yes, and of course SpiderMonkey.  For no particularly good reason I simply have 
the other two positioned in my mind as perhaps being more (technically) 
approachable for somebody who wanted to plunge into such an effort. I may well 
be misguided in that perception.

-Original Message-
From: Brendan Eich [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 25, 2008 10:16 PM
To: Allen Wirfs-Brock
Cc: Robert Sayre; es4-discuss; [EMAIL PROTECTED]
Subject: Re: ES 3.1 implementations?

On Jun 25, 2008, at 8:53 PM, Allen Wirfs-Brock wrote:

> It would be great if somebody wanted to work on a proof of concept
> ES 3.1 implementation in a open code bases such as such as Webkit
> or Rhino.

Don't forget SpiderMonkey.

> If anybody is interested in volunteering send a not to es3.x-
> [EMAIL PROTECTED]

There's the ES4 RI as well -- did you have anyone already lined up to
work on the 3.1 subset of it?

/be

>


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

RE: ES 3.1 implementations?

[Allen Wirfs-Brock]

It would be great if somebody wanted to work on a proof of concept ES 3.1 
implementation in a open code bases such as such as Webkit or Rhino.

If anybody is interested in volunteering send a not to [EMAIL PROTECTED]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Sayre
Sent: Wednesday, June 25, 2008 5:35 PM
To: es4-discuss; [EMAIL PROTECTED]
Subject: ES 3.1 implementations?

I am putting together feedback on the JSON features proposed for ES
3.1, and I was wondering if there any ES 3.1 implementations
available.

Given the limited scope of the spec, I would expect to see at least
one implementation completed soon if there isn't one. Maybe in Rhino
or something?

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."
___
Es3.x-discuss mailing list
[EMAIL PROTECTED]
https://mail.mozilla.org/listinfo/es3.x-discuss

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

RE: Brief Minutes [RE: ES3.1 WG phone conference 24 June 08:00 PT]

[Allen Wirfs-Brock]

Following up on the "Strict Mode" discussion...

As I advocated on the call, I think that by selecting "strict mode" a developer 
is really choosing to restrict themselves to using a subset of the complete 
language.  The future-proofing issues  of this relate to the possibility that 
there might be multiple such subsets that a developer might need to choose 
among.  Should there be multiple named "strict modes" to choose among, how 
should they be named, can "strictness" of a mode increase in future versions, 
etc?

I think some of the controversy could be eliminated if we simply eliminate the 
term "Strict Mode".  Instead I propose we have a "Use Subset" directive  and 
that we name specific subsets in a meaningful and generally positive manner.  
For example,  since the motivation of most of the proposed restrictions in 
ES3.1 strict mode is to provide a safer subset language I suggest that we call 
this subset "safety"  (or perhaps "safety1" or "safetyA"  or "safety2008" 
implying that in the future different safe subsets might be defined and we 
don't want to give undo importance to this initial one).

So, the first line of a "strict mode" compilation unit would now look like"
"use subset safety"

I would suggest that we actually define "use subset" such that a comma 
separated list of subsets is allowed.  So, if somebody decided to define a 
subset that only contained the features of ES3 you might see something like 
this:
"use subset safety,ES3"

Since subsets are sets of restrictions, listing multiple subsets means to take 
the union of the restrictions imposed by all of the listed subsets.  So "use 
subset safty,ES3" means that this compilation unit may only use those features 
defined by ECMA 262-3 and which are not excluded by the "safety" subset.  So, 
assuming that "safety" excludes use of the with statement, such a compilation 
unit could not include use of the with statement nor could it include any use 
of a feature that is new in ES3.1 or ES4.

Future versions of ECMAScript may add exclusions to a subset defined by an 
earlier version as long as the added exclusions only restrict capabilities that 
didn't exist in the earlier version. For example, ES 4 in supporting the ES3.1 
"safety" subset but add to it any features that are added in ES 4  but which 
are considered to be unsafe.

A future version may not add  exclusion to an pre-existing subset that 
restricts features that existed when the original subset was defined.  For 
example if ES3.14 or ES5 decided that the for-in statement was unsafe, it could 
not add that restriction to the "safety" subset.  However, it could define a 
new subset named perhaps "safety2010" that includes all the restrictions of the 
"safety" subset and in addition disallows use of the "for" statement.

If a compilation unit specifies a subset that is not known to the 
implementation that is processing it, that subset restriction is simply 
ignored. The code in the unit is still either valid or invalid on its own merit 
just like is the case when no subset had been specified.



_
From: Pratap Lakshman (VJ#SDK)
Sent: Tuesday, June 24, 2008 11:43 AM
To: Adam Peller; Sam Ruby; Mark S. Miller; Allen Wirfs-Brock; Pratap Lakshman 
(VJ#SDK)
Subject: Brief Minutes [RE: ES3.1 WG phone conference 24 June 08:00 PT]


Here are brief minutes from our call.
Please take a look, and let me know if you want any changes by your EOD.
I'll upload it to the wiki and send a copy to Patrick Charollais (ECMA) for 
posting on the ECMA site tomorrow night (Redmond time).

Attendees
Adam Peller (IBM)
Sam Ruby (IBM)
Mark Miller (Google)
Allen Wirfs-Brock (Microsoft)
Pratap Lakshman (Microsoft)

Agenda
On posting the latest draft to the wiki
Getters/Setters
Decimal
Setting up a review based on Lars' feedback on the 11 June draft

Minutes
Would like to add a couple more items to agenda that we can get to if we have 
the time (1) inconsistence language like "as if by the expression ..." 
pervasive in ES3 (e.g. section 11.1.4 Array Initializer: "create a new array as 
if by the expression new Array()"; needs to be fixed in ES3.1 (2) ES3/ES4 based 
review.

On posting the latest draft to the wiki
The latest draft has been uploaded to the wiki. This the draft as of 24 June 
2008 - it has all the edits related to the statics on Object, the introduction 
of the [[Extensible]] property, the revised notation for JSON, and placeholders 
for Decimal - by next week we should try to have a technically complete draft - 
the draft may still have some place holders but it should still be enough to 
get circulated within TC39 as an artifact that can be reviewed - by the time we 
mee

RE: More string indexing semantics issues

[Allen Wirfs-Brock]

Garrent: Thanks for the pointer to your analysis. Do you have any others that 
identify issues that could potentially be fixed in ES3.1?


I think in this case I have to agree with Maciej...Webkit appears to be doing 
the "right thing" by making a string appear to consistently have a set of 
numerically named readonly properties that exactly correspond to the elements 
of the string value.

In a clean-slate world, I think that should be the end of the discussion.  
However, we have backwards compatibility issues to consider.  By the book ES3 
allows numerically named properties to be added to String objects that are 
unrelated to the string value, and 2 out of the 3 widely used browser-based 
implementations that support property style access to the string value also 
allow such properties to be added.  Only Webkit deviates from this.  Right or 
wrong, from a pure compatibility perspective preserving that capability would 
be important **if we think that there is any significant usage of it**.  The 
fact that Safari seems to be getting away with its implementation without being 
badgered into conformance suggests that there probably isn't any such 
significant usage.

So, unless someone has some evidence that it is going to "break the web" I'm 
going to leave by ES3.1 specification the way it currently is written, which 
implements the observed behavior of Webkit.

Maciej: I assume you haven't heard of any significant web content being broken 
by this behavior.
Garrett:  Do you know of anything other than your test case that would be 
impacted if the standard adopted the Webkit behavior?

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

More string indexing semantics issues

[Allen Wirfs-Brock]

Assuming the string index semantics I defined in my previous message, what 
should the effect of setting a numeric property on a string whose property name 
is a valid character position into the string?

For example:
   var s = new String("abc")
s[1];   /* not valid in ES3, should yield "b" under extended semantics*/
s[1]  = "x";  /* valid in ES3, but has nothing to do with the string value 
*/
s[1];/*  both in ES3 and with extended semantics would yield "x"

Should the assignment, s[1] = "x", still be valid in the present if we support 
string indexing?

Argument for allowing:  It's backwards compatible.  There may be existing ES3 
programs that depend upon it.

Argument for disallowing:  Allowing characters of a string to be accessed using 
property access syntax makes the string elements appear as if they are actually 
properties. There appears to be a "joining" of s[1] and s.charAt[1}.
Since the value of a string is immutable, any property that is "joined" to a an 
element of a string value should be a read-only property.

My inclination would be to disallow, but preserving existing code is one of our 
top priorities. What do the existing implementation that support indexed access 
to string elements do?  If some of them disallow defining such properties then 
there is probably enough existing divergence that the compatibility issue 
doesn't really apply.

Second issue:
I defined string index property access in such a way that such properties 
appear to be non-enumerable.  Is this reasonable?  It's inconsistent with 
arrays. However, saying that they are enumerable implies that for-in should 
iterate over string element indexes which it now doesn't do.  Also what about 
meta operations like Object.prototype.hasOwnProperty?  My current semantics 
would cause it report true for string element indexes.  Is this reasonable?  
It's another set of incompatibilities.






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

RE: Semantics of "indexed" string access

[Allen Wirfs-Brock]

"abc"[1]   Would presumably parse as:

MemberExpression [ Expression ]

Whose semantic are:
1. Evaluate MemberExpression.
2. Call GetValue(Result(1)).
3. Evaluate Expression.
4. Call GetValue(Result(3)).
5. Call ToObject(Result(2)).
6. Call ToString(Result(4)).
7. Return a value of type Reference whose base object is Result(5) and whose 
property name is
Result(6).

Note that steps 1,2, and 5 amount to ToObject(GetValue("abc")).  
GetValue("abc") yields "abc" so this is really just ToObject("abc").  9.9 says 
ToObject when applied to a s primitive string: "Create a new String object 
whose [[value]] property is set to the value of the string.".  That string 
object becomes the base object of the resulting Reference.  So the literal get 
converted into an object that  has a [[Get]]
From: Brendan Eich [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 24, 2008 7:34 PM
To: Allen Wirfs-Brock; Maciej Stachowiak
Cc: [EMAIL PROTECTED] x-discuss; Pratap Lakshman (VJ#SDK); 
es4-discuss@mozilla.org es4-discuss
Subject: Re: Semantics of "indexed" string access

On Jun 24, 2008, at 6:39 PM, Allen Wirfs-Brock wrote:


Actually, the intent was to support "indexed" access to both string values and 
string wrapper objects.  I just didn't make it clear in the example.  The case 
analysis was intended to apply to both. My reading of section 11.2.1 is that  a 
string value is to be transformed into an object before any actual property 
access semantics are applied. Am I wrong?

No, the primitive string type (called "String", confusingly, in ES1-3 when it 
uses type names) is not an object. It has no internal methods such as [[Get]].

Specifying the indexed unit-string access semantic based on the wrapper String 
(spelled as in the language) object seems ok. I noted a Result(4) that should 
have been Result(6) in step 7, via private email to Allen (this type of error 
is going to happen a lot; count on it).

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

RE: Semantics of "indexed" string access

[Allen Wirfs-Brock]

Actually, the intent was to support "indexed" access to both string values and 
string wrapper objects.  I just didn't make it clear in the example.  The case 
analysis was intended to apply to both. My reading of section 11.2.1 is that  a 
string value is to be transformed into an object before any actual property 
access semantics are applied. Am I wrong?

Is the semantics I described really any different from array indexing?  I 
actually, borrowed some concepts from Array [[Put]] but it is most about 
maintaining the length invariant. Other than that I didn't find any array 
specific property indexing semantics in the ES3 spec.

From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 24, 2008 6:21 PM
To: Allen Wirfs-Brock
Cc: [EMAIL PROTECTED]; Pratap Lakshman (VJ#SDK); es4-discuss@mozilla.org
Subject: Re: Semantics of "indexed" string access


On Jun 24, 2008, at 5:46 PM, Allen Wirfs-Brock wrote:


I've taken a crack at cleaning up Pratap's initial specification for supporting 
direct indexing of strings, eg "abc"[1] yields "b"

Here are the semantics that seemed to make sense:

s[n]
1)  If s has an own property whose name is the same as the value of n, the 
value of that property is returned.

Since s is a string value, not an object, then it cannot have any own 
properties. The autogenerated wrapper for s does have some own propertied.


2) else If the value of n is convertible to a number that is within the bounds 
of the string value, return a string containing the corresponding character
3) else if try to resolve n as the name of an inherited property
4) else return undefined.

In other words, indexing into a string with a "valid" index returns that 
appropriate character unless somebody has explicitly defined a property named 
by that index on the object.

It is not possible to define a custom property on a string value. On a string 
object you could.

I would suggest it makes more sense to make index properties of a string act 
like index properties of an array, but read-only.

Regards,
Maciej

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

RE: Semantics of "indexed" string access

[Allen Wirfs-Brock]

A slightly revised (last two steps) version of the pseudo-code:

15.5.5.2 [[GetOwnProperty]] (P)
String objects use a variation of the [[GetOwnProperty]] method used for other 
native ECMAScript objects (8.6.2.1.2).
Assume S is a String object and P is a string.
When the [[GetOwnProperty]] method of S is called with property name P, the 
following steps are taken:
1.  Call the default [[GetOwnProperty]] method (8.6.2.1.2) with S as the 
this value and argument P.
2.  If Result(1) is not undefined return Result(1).
3.  If P is not an array index (15.4) , return undefined.
4.  Call ToString, giving S as its argument.
5.  Call ToInteger(P).
6.  Compute the number of characters in Result(4).
7.  If Result(5) is less than 0 or is not less than Result(4), return 
undefined.
8.  Create a string of length 1, containing one character from Result(4), 
namely the character at position Result(5), where the first (leftmost) 
character in Result(4) is considered to be at position 0, the next one at 
position 1, and so on.
9.  Return a DDesc with attributes {[[Value]]: Result(8), [[Enumerable]]: 
false, [[Writeable]]: false, [[Dynamic]]: false]


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Allen Wirfs-Brock
Sent: Tuesday, June 24, 2008 5:46 PM
To: [EMAIL PROTECTED]; Pratap Lakshman (VJ#SDK)
Cc: es4-discuss@mozilla.org
Subject: Semantics of "indexed" string access

I've taken a crack at cleaning up Pratap's initial specification for supporting 
direct indexing of strings, eg "abc"[1] yields "b"

Here are the semantics that seemed to make sense:

s[n]
1)  If s has an own property whose name is the same as the value of n, the 
value of that property is returned.
2) else If the value of n is convertible to a number that is within the bounds 
of the string value, return a string containing the corresponding character
3) else if try to resolve n as the name of an inherited property
4) else return undefined.

In other words, indexing into a string with a "valid" index returns that 
appropriate character unless somebody has explicitly defined a property named 
by that index on the object.
If the "index" is not within the bounds of the string it is treated like a 
normal property access - If it isn't defined either locally or on the parent 
chain the result is undefined.

I've specified this by "over-riding" the definition of [[GetOwnProperty]] for 
string instances".  Note that literal strings as in the example above will have 
been transformed into objects by the property access semantics of 11.2.1

15.5.5.2 [[GetOwnProperty]] (P)
String objects use a variation of the [[GetOwnProperty]] method used for other 
native ECMAScript objects (8.6.2.1.2).
Assume S is a String object and P is a string.
When the [[GetOwnProperty]] method of S is called with property name P, the 
following steps are taken:
10.   Call the default [[GetOwnProperty]] method (8.6.2.1.2) with S as the this 
value and argument P.
11.   If Result(1) is not undefined return Result(1).
12.   If P is not an array index (15.4) , return undefined.
13.   Call ToString, giving S as its argument.
14.   Call ToInteger(P).
15.   Compute the number of characters in Result(4).
16.   If Result(5) is less than 0 or is not less than Result(4), return 
undefined.
17.   Return a string of length 1, containing one character from Result(4), 
namely the character at position Result(5), where the first (leftmost) 
character in Result(4) is considered to be at position 0, the next one at 
position 1, and so on.


Is this a reasonable semantics? Does it match what browsers have already 
implemented?
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Semantics of "indexed" string access

[Allen Wirfs-Brock]

I've taken a crack at cleaning up Pratap's initial specification for supporting 
direct indexing of strings, eg "abc"[1] yields "b"

Here are the semantics that seemed to make sense:

s[n]
1)  If s has an own property whose name is the same as the value of n, the 
value of that property is returned.
2) else If the value of n is convertible to a number that is within the bounds 
of the string value, return a string containing the corresponding character
3) else if try to resolve n as the name of an inherited property
4) else return undefined.

In other words, indexing into a string with a "valid" index returns that 
appropriate character unless somebody has explicitly defined a property named 
by that index on the object.
If the "index" is not within the bounds of the string it is treated like a 
normal property access - If it isn't defined either locally or on the parent 
chain the result is undefined.

I've specified this by "over-riding" the definition of [[GetOwnProperty]] for 
string instances".  Note that literal strings as in the example above will have 
been transformed into objects by the property access semantics of 11.2.1

15.5.5.2 [[GetOwnProperty]] (P)
String objects use a variation of the [[GetOwnProperty]] method used for other 
native ECMAScript objects (8.6.2.1.2).
Assume S is a String object and P is a string.
When the [[GetOwnProperty]] method of S is called with property name P, the 
following steps are taken:
1.  Call the default [[GetOwnProperty]] method (8.6.2.1.2) with S as the 
this value and argument P.
2.  If Result(1) is not undefined return Result(1).
3.  If P is not an array index (15.4) , return undefined.
4.  Call ToString, giving S as its argument.
5.  Call ToInteger(P).
6.  Compute the number of characters in Result(4).
7.  If Result(5) is less than 0 or is not less than Result(4), return 
undefined.
8.  Return a string of length 1, containing one character from Result(4), 
namely the character at position Result(5), where the first (leftmost) 
character in Result(4) is considered to be at position 0, the next one at 
position 1, and so on.


Is this a reasonable semantics? Does it match what browsers have already 
implemented?
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss