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
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 initi
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 acc
imitive 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
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" un
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
numeri
ddition 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
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
-
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 o
s "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 co
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.
Fro
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-
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 we
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
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 P
" 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;
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
conse
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: Wednesda
ith [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]>:
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: We
tions.
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-
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 b
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 PROT
s 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
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
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
t;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: Wedne
ty]].
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 m
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 th
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 PRO
-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 prototyp
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; B
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 coul
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 m
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 ha
thing 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:
TED]
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 m
ty 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
ould 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
Subje
-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
> -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 SpiderM
> -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
> -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
f 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,
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
> 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
46 matches
Mail list logo
