ES4 draft last call: line continuation in string and regex literals
Last call for the line continuation spec:
http://wiki.ecmascript.org/doku.php?id=spec:line_continuation_in_strings
("Last call" = it will be taken into the language spec within a week or
so unless there's opposition now.)
--lars
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Vector
> -Original Message- > From: Eylon Stroh > Sent: 7. mars 2008 12:22 > To: Lars Hansen; es4-discuss@mozilla.org > Subject: RE: ES4 draft: Vector > > << FIXME Need to check a detail of the type system, namely > whether Vector. is a subtype of Vector. if T is a > subtype of U and U is not *. >> > > It shouldn't be. Consider Bar <: Foo, Baz <: Foo: > > let baz:Vector. = new Vector.(); > let foo:Vector. = baz; // allowed if Vector. <: Vector. > foo.add(new Bar()); That would fail with a run-time check since Bar is not <: Baz. Note that the type annotations here do not imply any absence of run-time checks. For this program, the annotations make no difference and could be left out. (Annotations only have a run-time effect in that they cause errors to be thrown on assigning to variables and properties if the types don't match, and they cause some primitive values to be converted to other primitive values.) > let bazItem:Baz = baz.get(0); // type error! Wouldn't get that far. Anyhow we've decided against covariant vector types except that Vector. <: Vector.<*> for all T. > Other comments: > > push() is missing "length++;" It is not; writing to this[length] updates length. > sort() is missing "return this;" Indeed. > I think that the first for loop in unshift() should read > > for ( let i=1 ; i <= oldlimit ; i++ ) > this[newlimit-i] = this[oldlimit-i]; I think the test is i <= numitems but otherwise you're right, it needs to run from 1. > also, "return newlength;" should be > length = newlimit; > return length; > assuming that the length setter only sets the length > property, without setting any default values (otherwise it > would need to be moved up to before the for loops). Superficially this is the same issue as for push(), length has already been updated by the assignments in the first loop. So the explicit update is not needed before return. But the first loop is not actually correct, it needs to set the new length first otherwise the assignments will be illegal if more than one value is unshifted in. Thanks for the careful reading. --lars > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen > Sent: Monday, March 03, 2008 12:36 PM > To: es4-discuss@mozilla.org > Subject: ES4 draft: Vector > > I enclose a slightly incomplete/rough draft for the Vector class. > Please comment. > > --lars > ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
ES4 draft last call: Line terminator normalization
Last call for the line terminator normalization spec: http://wiki.ecmascript.org/doku.php?id=spec:line_terminator_normalizatio n --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Object
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of zwetan > Sent: 7. mars 2008 19:28 > To: Brendan Eich > Cc: es4-discuss@mozilla.org es4-discuss; Yuh-Ruey Chen; Erik Arvidsson > Subject: Re: ES4 draft: Object > > why not have a global utility function, maybe in the magic namespace The "magic" namespace (like "informational" and "helper") is a specification artifact, it does not exist in an implementation. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Object
On 2008-03-07, at 22:43 EST, Brendan Eich wrote: > The goal is to find the minimum amount of mutating meta-programming > sharpness for this "make certain properties non-enumerable" tool. If > it can be done with a one-time namespace qualification step, that > wins. A few comments: I am confused. I guess I thought everything was in a namespace, just that there is a default namespace that things with no explicit namespace are in. Which makes me wonder how the namespace/not- enumerable proposal will really work. I think it is absolutely right that fixtures are not enumerable. And a bug that things that would have been fixtures if you had them are enumerable in es3. It seems to me that for-in/enumerability are all about Maps, maybe now that we have Maps (and classes with fixtures), we don't have to worry about enumerability in Objects so much. Finally, for debugging, I would want to be able to find all the properties of an object, non-enumerable and fixtures included. Will there be a way to introspect like that? ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Object
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of P T Withington > Sent: 8. mars 2008 10:10 > To: Brendan Eich > Cc: zwetan; es4-discuss@mozilla.org es4-discuss; Yuh-Ruey > Chen; Erik Arvidsson > Subject: Re: ES4 draft: Object > > On 2008-03-07, at 22:43 EST, Brendan Eich wrote: > > > The goal is to find the minimum amount of mutating meta-programming > > sharpness for this "make certain properties non-enumerable" > tool. If > > it can be done with a one-time namespace qualification step, that > > wins. > > A few comments: > > I am confused. I guess I thought everything was in a > namespace, just that there is a default namespace that things > with no explicit namespace are in. Which makes me wonder how > the namespace/not- enumerable proposal will really work. Some namespaces are "public" and distinguished thereby, properties in these namespaces would be enumerated. One of the public namespaces is the default namespace that things with no explicit namespace are in. (We're still fine-tuning the details of that.) > Finally, for debugging, I would want to be able to find all > the properties of an object, non-enumerable and fixtures > included. Will there be a way to introspect like that? Not certain yet. Being able to "just do it" is a security concern if you think namespaces are in part about hiding access to private data. (Debugging facilities in the language are not a good idea if there is any chance at all that some of the code in a program may be hostile. We have to make a choice about that when we write the spec for the reflection mechanism.) --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Object
Brendan Eich wrote: > > - Users may think this dontenum namespace is magical and yet another > > thing to keep in mind, when it really just relies on the namespace > > trick > > you mentioned. With the introduction of classes and namespaces, the > > rules of enumerability are already more complex, so this adds to the > > cognitive load slightly. > > Slightly, but it takes away the magic DontEnum attribute, formerly > hogged by the specification and magic predefined objects. > But doesn't DontEnum still have to be there for ES3 objects? How else would you prevent the enumeration of ES3 builtin methods, e.g. Object.prototype.toString()? Or is there some more open namespace magic that I'm unware of? > > BTW, if setPropertyIsEnumerable() is added, > > would it be possible to make fixtures enumerable? Enumerability is > > orthogonal to static analysis (which fixtures are meant to help with), > > so I don't see why not. > > This gets to the heart of the public vs. public-in-context-of-class- > or-package issue. We need to sort this out to find out exactly how > orthogonal enumerability is, as well as decide how flexible it should > be. > Well, I think the only overlap is that public-in-class-context methods (or any method really) default to be non-public in terms of enumerability > > - The name sucks :p > > Indeed. How about 'hidden' or 'nonEnumerable'? > I'd prefer 'hidden', since 'nonEnumerable' implies more strongly that a prop needs to be in that namespace to not be enumerable, when that's not the case. Which gets me back to the cognitive load issue. Even with a name like 'hidden', they may think they may have to do some funky syntax like |obj.hidden::other_ns::prop| do hide a prop in another namespace. While we're on the topic of namespaces, I read in the ES4 overview: "In addition, the names internal, public, protected, and private denote namespace values, but the values depend on the context of the use." As the wiki doesn't talk about this, and the online spec is inaccessible/outdated, can you elaborate on this? I wonder if 'private' could be used somehow for enumerability. -Yuh-Ruey Chen ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Object
On Mar 8, 2008, at 1:16 PM, Yuh-Ruey Chen wrote:
> Brendan Eich wrote:
>>> - Users may think this dontenum namespace is magical and yet another
>>> thing to keep in mind, when it really just relies on the namespace
>>> trick
>>> you mentioned. With the introduction of classes and namespaces, the
>>> rules of enumerability are already more complex, so this adds to the
>>> cognitive load slightly.
>>
>> Slightly, but it takes away the magic DontEnum attribute, formerly
>> hogged by the specification and magic predefined objects.
>
> But doesn't DontEnum still have to be there for ES3 objects? How else
> would you prevent the enumeration of ES3 builtin methods, e.g.
> Object.prototype.toString()? Or is there some more open namespace
> magic
> that I'm unware of?
ES3 code can't detect namespaces, so arguably shouldn't care if we
were to implement DontEnum using an open namespace. But this could be
a problem for mixed ES3 and ES4 scenarios where the ES4 code does
introspect via Name objects and is surprised to find "ES3" objects
with qualified property names.
>>> BTW, if setPropertyIsEnumerable() is added,
>>> would it be possible to make fixtures enumerable? Enumerability is
>>> orthogonal to static analysis (which fixtures are meant to help
>>> with),
>>> so I don't see why not.
>>
>> This gets to the heart of the public vs. public-in-context-of-class-
>> or-package issue. We need to sort this out to find out exactly how
>> orthogonal enumerability is, as well as decide how flexible it should
>> be.
>>
>
> Well, I think the only overlap is that public-in-class-context methods
> (or any method really) default to be non-public in terms of
> enumerability
Is that the right design?
dynamic class C {
public var fixture;
function C() { this.expando = 42; }
}
for (var i in new C)
intrinsic::print(i);
wouldn't you expect to see "expando" printed? Is it printed because
the default namespace for expando is the public-default one? I
believe it is not, in the current proposal and the RI. Rather, each
class or package gets a nonce-named public namespace, different from
every other such per-class or per-package public. IIRC package trumps
class -- classes within a package share the package's nonce-named
public namespace (Jeff, Lars, please correct me if I'm wrong).
> While we're on the topic of namespaces, I read in the ES4 overview:
> "In
> addition, the names internal, public, protected, and private denote
> namespace values, but the values depend on the context of the use." As
> the wiki doesn't talk about this, and the online spec is
> inaccessible/outdated, can you elaborate on this? I wonder if
> 'private'
> could be used somehow for enumerability.
This is the entire issue. See above and let me know if that's unclear.
/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
server-side ECMAScript 4?
Are there any Open Source projects to develop server-side ECMAScript 4? I'm in preliminary stages of locating (or starting if none exists) a project to use Tamarin/ActionScript 3 on both server and client. This would naturally evolve into ES4 once that is final. Researching to see what exists. My tentative thought is to adapt Whitebeam http://www.whitebeam.org/ from SpiderMonkey to Tamarin. This would provide an XML-based Web Application Server. Targeting Flash Player 9 on the client side, as a rich media platform. (and Flash Lite 2 on mobile devices -- looking forward to a future version with AS3 support). If anyone has an interest, or any relevant information, please let me know. ~ToolmakerSteve [EMAIL PROTECTED] http://toolmakersteve.com ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft last call: line continuation in string and regex literals
On Mar 8, 2008, at 8:20 AM, Lars Hansen wrote:
> Last call for the line continuation spec:
>
> http://wiki.ecmascript.org/doku.php?id=spec:line_continuation_in_strings
>
> ("Last call" = it will be taken into the language spec within a week
> or
> so unless there's opposition now.)
This (and the line terminator normalization draft) seem to be in
restricted parts of the wiki. Could they go somewhere public?
- Maciej
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Feature specs namespace in wiki.ecmascript.org
Hi, The 'spec' directory we were using to post feature specs is not publicly visible (my bad). To avoid making all the content in that directory (most of which is out of date) generally visible, I've created a new directory named 'feature specs'. http://wiki.ecmascript.org/doku.php?id=features_specs:feature_specs You'll find the currently active speclets posted there. Jd ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
ES4 process tweaks
Hi, Now that feature specs are starting to flow, we should pin down the process for reviewing these specs. Here is a proposal. The basic elements of the process: - Spec distribution - Discussion by email - Tickets for open issues - Last call for comments - Live discussion at monthly F2F meetings - Phone calls as needed Key points: - Individual feature specs distributed by implementer/designer as discussed previously. - Discussion carried out on es4-discuss so that everyone has a voice and there is a full record of the discussion. - Unresolved issues get recorded in Trac tickets and linked from the relevant feature spec - Last call for comments just to mark the end of the discussion and give everyone a chance to weigh in. No doubt as the feature specs get woven together new issues will become apparent. This milestone is simply to agree on what the known issues are at a specific point in time. - F2F meetings should be primarily for drafting specs and having "last call" discussions. It will be good to limit the review discussions as much as possible to es4-discuss so that everyone is included. - Phone meetings should be scheduled only as needed. They neither have the visibility of es4-discuss nor the bandwidth of the F2F meetings, and so don't serve our current communication needs well. Thoughts? Jd ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: server-side ECMAScript 4?
We will be using our ES4 implementation server side. Mainly for embedded uses, but it could apply more broadly. We have a server side page technology like ASP -- called ESP. This simply processes <% code %> sequences and effectively converts the web page into javascript code that is then processed. We've used this in our Appweb embedded web server for quite a while, but the javascript language was very limited. Still it has worked well. Upgrading to ES4 will give a very sweet server side environment. Of course, we have had to add quite a bit of extra library code suitable for server side processing. What kind of server side were you interested in? Michael O'Brien Mbedthis Software On Mar 8, 2008, at 3:14 PM, ToolmakerSteve98 wrote: Are there any Open Source projects to develop server-side ECMAScript 4? I'm in preliminary stages of locating (or starting if none exists) a project to use Tamarin/ActionScript 3 on both server and client. This would naturally evolve into ES4 once that is final. Researching to see what exists. My tentative thought is to adapt Whitebeam http://www.whitebeam.org/ from SpiderMonkey to Tamarin. This would provide an XML-based Web Application Server. Targeting Flash Player 9 on the client side, as a rich media platform. (and Flash Lite 2 on mobile devices -- looking forward to a future version with AS3 support). If anyone has an interest, or any relevant information, please let me know. ~ToolmakerSteve [EMAIL PROTECTED] http://toolmakersteve.com ___ 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: ES4 draft: Namespace
do I understand well that E4X will be removed from ES4 ??? this is so wrong i can not even believe it... try to parse XML in .NET/Java/PHP/whatever... the ONLY elegant and straightforward way to do it is E4X imho but ok let's stay on the standard and on the web, look at how browsers parse XML without E4X see why those projects exists http://dev.abiss.gr/sarissa/ http://code.google.com/p/ajaxslt/ yeah that's the reality in browsers XML parsing sucks because every browser does its own cooking... so again, even if the E4X spec is buggy etc. would it not be better to keep E4X and/or try to improve it within ES4 ? I know this ML is focused on specs, but I can really not understand why something as E4X which is easy and powerfull to use for any dev would be removed zwetan ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Namespace
On 3/8/08, zwetan <[EMAIL PROTECTED]> wrote: > do I understand well that E4X will be removed from ES4 ??? It was never in ES4 to begin with. --lars > this is so wrong i can not even believe it... > > try to parse XML in .NET/Java/PHP/whatever... > the ONLY elegant and straightforward way to do it is E4X imho > > but ok let's stay on the standard and on the web, > look at how browsers parse XML without E4X > > see why those projects exists > http://dev.abiss.gr/sarissa/ > http://code.google.com/p/ajaxslt/ > > yeah that's the reality in browsers XML parsing sucks > because every browser does its own cooking... > > so again, even if the E4X spec is buggy etc. > would it not be better to keep E4X and/or try to improve it within ES4 ? > > I know this ML is focused on specs, > but I can really not understand why something as E4X > which is easy and powerfull to use for any dev would be removed > > > zwetan > > ___ > 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: ES4 draft: Namespace
On Mar 8, 2008, at 8:58 PM, zwetan wrote: > do I understand well that E4X will be removed from ES4 ??? Not removed, not included. It's a separate Ecma standard. As I wrote (you read :-/), the spec is in poor enough shape, and feedback from our users suggest enough changes, that we didn't want to delay ES4 to include it. More important, we do not believe it is proper to mandate E4X support as a normative part of ES4. ES3 is implemented in very small devices and used by many other standards. Some of those implementations and standards have nothing to do with XML. > this is so wrong i can not even believe it... What would be wrong is your apparent stance: require all ES3 implementations contemplating ES4 to implement E4X, even if XML is irrelevant. Your message goes on to decry the state of XML parsing in browsers, but E4X is not really an XML parser. It is out of date regarding XML 1.1 and namespaces. It has no provision for streaming (SAX-style parsing). Its "DOM" duplicates the browsers' DOMs with gratuitous differences, yet (optionally) requires the two DOMs to be synchronized. How mandating E4X as part of ES4 would help XML parsing in browsers is beyond me. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
