Semantics of indexed string access

2008-06-24 Thread 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.

RE: Semantics of indexed string access

2008-06-24 Thread Allen Wirfs-Brock
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

More string indexing semantics issues

2008-06-24 Thread 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

RE: More string indexing semantics issues

2008-06-25 Thread 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

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

2008-06-25 Thread Allen Wirfs-Brock
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

RE: ES 3.1 implementations?

2008-06-26 Thread Allen Wirfs-Brock
- 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

RE: dynamic attribute nomenclature

2008-06-26 Thread 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

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

2008-06-27 Thread 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

early reporting of malformed regex literals

2008-06-27 Thread 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

RE: for-in statement: null and undefined

2008-07-03 Thread 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

RE: Newly revised Section 10 for ES3.1.

2008-07-09 Thread 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

RE: Newly revised Section 10 for ES3.1.

2008-07-09 Thread Allen Wirfs-Brock
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

Update on ES3.1 block scoped function declarations

2008-07-10 Thread 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

RE: Update on ES3.1 block scoped function declarations

2008-07-10 Thread 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

RE: Update on ES3.1 block scoped function declarations

2008-07-10 Thread Allen Wirfs-Brock
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

RE: Two interoperable implementations rule

2008-07-11 Thread 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

RE: ES3.1 Object static methods rationale document

2008-07-16 Thread Allen Wirfs-Brock
:[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

RE: A read/write __proto__ that can vanish

2008-07-16 Thread 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

RE: ES3.1 Object static methods rationale document

2008-07-16 Thread Allen Wirfs-Brock
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

RE: ES3.1 Object static methods rationale document

2008-07-16 Thread Allen Wirfs-Brock
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

RE: ES3.1 Object static methods rationale document

2008-07-16 Thread 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

RE: ES3.1 Object static methods rationale document

2008-07-16 Thread 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

RE: ES3.1 Object static methods rationale document

2008-07-16 Thread 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

RE: ES3.1 Object static methods rationale document

2008-07-16 Thread Allen Wirfs-Brock
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

RE: ES3.1 Object static methods rationale document

2008-07-17 Thread Allen Wirfs-Brock
, 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

RE: ES3.1 Object static methods rationale document

2008-07-18 Thread Allen Wirfs-Brock
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

RE: ES3.1 Object static methods rationale document

2008-07-18 Thread Allen Wirfs-Brock
. 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

RE: ES3.1 Object static methods rationale document

2008-07-18 Thread 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.

RE: ES3.1 Object static methods rationale document

2008-07-18 Thread 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

RE: ES3.1 Object static methods rationale document

2008-07-18 Thread 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

RE: ES3.1 Object static methods rationale document

2008-07-19 Thread Allen Wirfs-Brock
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

Notes from 8/7 ES3.1 Teleconference

2008-08-07 Thread 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

RE: ECMAScript Harmony

2008-08-13 Thread 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