Re: ES6 “modes” and user-friendliness
I think you've misunderstood. There's nothing in my New Year's email about getting ES6 semantics when you find an occurrence of a particular feature (that kind of thing was just a side conversation in the mega-thread, and a very ill-conceived one IMO). The proposal is that within the context of a module, you get a few small changes to the semantics **for the code within the module** -- and nothing else. There's no scanning for particular features. There's no language version detection. There's no versioning at all. ES6 is an update to the language like every other edition of ECMA-262 has been. Browsers don't have ES3 modes and ES6 modes. They just have ECMAScript. Ah, that makes sense, the thread you mentioned got me confused. Then for language implementors, there are three modes/semantics: 1. module = ES6 – some changes break with ES5.strict 2. use strict = ES5.strict + all ES6 constructs that are backward-compatible 3. otherwise = ES3 + all ES6 constructs that are backward-compatible It’s a tiny bit messy, but I can see that for developers, the illusion of a single ES6 is more or less intact. Seems like the best possible solution. Given that most people are bound to use modules and given that they are a very convenient “switch”, wouldn’t it be best to introduce as many breaking changes via #1 now (as opposed to later, in ES7 etc.)? Especially removing window from the scope chain. Mark’s email [1] seems to suggest just two modes (#1 being a superset of #2 = subsuming it), but using module as a switch, distinguishing #1 and #2 might be worth it. [1] https://mail.mozilla.org/pipermail/es-discuss/2012-January/019195.html -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma Home: rauschma.de Blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block Lambdas: break and continue
Grant Husbands
January 16, 2012
5:33 PM
Brendan Eich wrote:
2. Variation on empty label: support "do" as a reserved-identifier label
do: arr.forEach {|o|
if (...) break;
...
}
This seems like a sound way of doing it, indeed (I omitted your first
one because I prefer this one).
Me too. Had to throw the shorter one out to give it its due.
It avoids the more egregious syntax
conflicts and is indicative of being interesting to break/continue.
Combined with the break-with and continue-with statements, elsewhere
in this thread, it makes block lambdas better than anonymous functions
currently are in nearly all cases, along with making it easier to
replace loops with callback-based iteration.
I will add strawman sections for these extensions to block_lamda_revival
in a bit.
To complete the Smalltalk homage we would want this in expressions, and
we'd also want do: to take a block-lambda directly, in addition to a
CallWithBlockArguments.
Would it call that block-lambda with no arguments?
If the block-lambda takes no arguments, yes. But I'm thinking of
CoffeeScript's do operator, which passes lexical references of the same
name as the block-lambda's parameters:
http://coffeescript.org/#try:list%20%3D%20[1%2C%202%2C%203]%0Afor%20x%20in%20list%0A%20%20do%20%28x%29%20-%3E%0A%20%20%20%20alert%20x
list = [1, 2, 3]
for x in list
do (x) -
alert x
which for example translates to:
var list, x, _fn, _i, _len;
list = [1, 2, 3];
_fn = function(x) {
return alert(x);
};
for (_i = 0, _len = list.length; _i _len; _i++) {
x = list[_i];
_fn(x);
}
Apologies for the CoffeeScript if it's not your thing, readers. Here's
the block-lambda with do: version:
let list = [1, 2, 3]
for (let x of list) {
do: { |x|
alert x
}
}
But of course, Harmony for-let-of and for-let-in loops provide a fresh
binding per iteration, so this do: is not needed to capture each
iteration's i value. Let's use old-style for:
let x;
for (x = 1; x 4; x++) {
do: { |x|
alert x
}
}
Here the single let x binding is prone to being captured with its final
value, 4. The do: calls its block-lambda argument with each x value in
turn, so (e.g.) the block-lambda can safely close over its parameter x
and get each value in [1, 2, 3].
This variation is future-hostile to leading-colon as statement- or
_expression_-starting special forms (see http://wiki.ecmascript.org
/doku.php?id=strawman:return_to_label). I think that this is
acceptable but I could be missing something.
I think I'm misreading, but I'm not seeing how "do:" and "return :"
conflict.
You're right, I was mis-remembering the return-to-label details.
If break-with and continue-with get specced, they would
cover the same use case, anyway.
Return-to-label has been fading for a while, it dates from an earlier
lambda proposal era. I agree break/continue-with do the job. I'll talk
to Allen about those a bit tomorrow.
I don't know how the process works, but I'd be happy to assist in the
creation of additional strawmen to cover these (potentially later)
additions to block lambdas and other blocks, if consensus is reached.
I don't want to jump the gun, though.
I thought about new strawmen but still think it better to add do: and
possibly break/continue-with to block-lambda revival to avoid too many
little wiki pages. b/c-with, perhaps, deserve their own page but it's
easy to split if necessary.
Thanks for the offer to help, I may take you up on it yet. And thanks
for the discussion.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A different semantics for WeakMap#get default value
Le 17/01/2012 01:46, Kris Kowal a écrit : On Mon, Jan 16, 2012 at 4:39 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: then the method should be called getOrSetIfNotThere(obj, def) 'cause get() would mislead too much I’ve been calling this method getset for about three years, hoping it would catch on :P https://github.com/kriskowal/narwhal-lib/blob/f182f2f0a952d75f06b0ebe142696056d2933501/lib/narwhal/util.js Indeed, I thought afterwards, that I could just as well create my own function and my own abstraction. It can be built efficiently on top of the current API, so everything's good. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 “modes” and user-friendliness
1. module = ES6 – some changes break with ES5.strict some changes break with ES5.strict is confusing -- do you mean 'let' works instead of being a future reserved word, whereas in (3, below) 'let' is not reserved at all? I’m not sure about specifics, I mean “ES6 things that are not backward-compatible with with ES5.strict” (if those exist, but it seems like they do). -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma Home: rauschma.de Blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A different semantics for WeakMap#get default value
Le 17/01/2012 01:53, Kris Kowal a écrit : For what it’s worth, Python dictionaries have .get(key, default) and .setdefault(key, default). The former is non-mutating. Its behavior is also different depending on arguments length. If the default is not passed, it will throw an exception. If a default is passed, even if that default is None, it will not throw an exception. I’ve found both forms useful. A use case I have in my case is that the default value may be different. For instance, generating a new number. I think that generators could do the trick here, but when using a generator as the default argument of .setDefault, how can the engine tell if i want it to use the generator as value or as value generator? David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 “modes” and user-friendliness
But in practice, strict mode can fade away as a transitional concept from ES5 that, while still spec'ed and implemented, doesn't get used much in practice. Modules carry the torch of ES5-strict and take it even further, and become the actual mode that gets used in practice, both because it is a useful feature independent of the language cleanups in carries with it, and because it doesn't require a noisy opt-in pragma. So the language has 3 modes in the spec, but in practice only 2 that matter. Crystal clear now, thanks! -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma Home: rauschma.de Blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block Lambdas: break and continue
To complete the Smalltalk homage we would want this [the label do:] in expressions, and we'd also want do: to take a block-lambda directly, in addition to a CallWithBlockArguments. Minor possibility of future-hostility: Should real keyword arguments ever make it to ECMAScript, labels such as do: seem an obvious choice. -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma Home: rauschma.de Blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 “modes” and user-friendliness
On Tue, Jan 17, 2012 at 7:30 AM, Axel Rauschmayer a...@rauschma.de wrote: Nitpick - None of the above = ES3 semantics That should be ES5 (non-strict) semantics. There are (a few) incompatible changes between ES3 and ES5, and you don't want to reintroduce the ES3 behavior (e.g., RegExp literal instance sharing). /L ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 “modes” and user-friendliness
But in practice, strict mode can fade away as a transitional concept from ES5 that, while still spec'ed and implemented, doesn't get used much in practice. Modules carry the torch of ES5-strict and take it even further, and become the actual mode that gets used in practice, both because it is a useful feature independent of the language cleanups in carries with it, and because it doesn't require a noisy opt-in pragma. So the language has 3 modes in the spec, but in practice only 2 that matter. One more question: Is there an opt-in strategy should a version after ES.next introduce breaking changes? That might be something worth planning for. Presumably modules will make it easier to encapsulate this kind of change. -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma Home: rauschma.de Blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
Andrea Giammarchi-2 wrote:
You are underlying my points too .. I am dealing on daily basis with
highly
dependent little modules and the build procedure takes care of packing
everything together before deployment.
However, we are using a synchronous version of require, similar to the one
used in node.js but that does not scale the day we would like to go
asynchronous in order to lazy load on demand only needed code.
On our side we're using version of require that's exactly same as in Node.js
(we also use Node.js and some modules are used on both sides) and
asynchronous loading in our case would rather be on package level not module
level (Node.js thinking) but even not exactly that way. It's more about
packs of modules that are needed to run other functionality (that we prefer
to load on demand) and those modules may come from various packages. That's
the approach we currently feel is right. We're using modules-webmake [1] for
client-side builds, but it's still limited as it doesn't support yet
intelligent split so modules are not duplicated in two different packs,
however we plan to address that soon.
Andrea Giammarchi-2 wrote:
Specially on mobile HTML5 applications where the manifest file is
included,
the lazy loading is handled by the browser itself and the module will be
almost instantly available once required later on if this was present in
the manifest.
What is missing is simply a common way that scales across all requirements
and I am sure you are using similar approach we do, stripping out
requires,
used only to order file inclusion before minification, using synchronous
loading on demand during debug ... isn't it?
We don't strip out requires, we were thinking about that, as it would
produce bit shorter and cleaner code (thinking one file) but the more we
work with Node.js style modules the more we acknowledge it may be quite hard
to achieve (unless you stick to some strict simple rules) but still I don't
see it as big deal, footprint that is currently added by modules-webmake[1]
is only 55 lines of code, and so far we don't feel it affects performance of
our applications.
We debug with not minified version of generated file, output from webmake is
very clear, and modules that were concatenated are not changed and usually
not big so it's easy to get around.
Andrea Giammarchi-2 wrote:
This is OK as long as your requirements won't change and, talking about
google, they do lazy load on demand many parts of their namespace too in
different applications 'cause a core of 1Mb does not simply scale over 3G
connections ... if you don't need that functionality instantly then why
creating such big package?
var module = require(module);
is totally fine but
require(module, function (module) {
// is totally fine too
});
latter could be synchronous in node.js and asynchronous in the web, who
cares, as long as it scales for all scenarios ... don't you agree?
Personally I don't like the need of extra closure. I want to be able to
write my code directly in a file. It may be a picking, but it's like
introducing to each of your modules extra maintenance code which has nothing
to do with logic of that module, I tend to avoid that as much as possible.
Andrea Giammarchi-2 wrote:
About AMD, yuno is 1Kb minzipped and it resolve dependencies with
parallels
downloads so you might be interested in having a look.
I looked at that with interest right when you published it, but currently I
really like the way modules work in Node.js, I'm fine with modules-webmake,
and I think it's currently the closest you can get to what will be
introduced in future with Harmony, so I plan to stick to that.
[1] https://github.com/medikoo/modules-webmake
--
Mariusz Nowak
twitter: http://twitter.com/medikoo
github: https://github.com/medikoo
-
Mariusz Nowak
https://github.com/medikoo
--
View this message in context:
http://old.nabble.com/Harmony-modules-feedback-tp33125975p33153281.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
rauschma wrote: @Andrea, Mariusz: Are you aware of the RequireJS optimizer [1]? It can be used together with almond [2], an AMD loader with minimal footprint. [1] http://requirejs.org/docs/optimization.html [2] https://github.com/jrburke/almond @Axel I read about it before, when we talk about synchronous loading then Node.js style modules with help of modules-webmake[1] is simpler and more powerful. I feel it's obvious. [1] https://github.com/medikoo/modules-webmake -- Mariusz Nowak twitter: http://twitter.com/medikoo github: https://github.com/medikoo - Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/Harmony-modules-feedback-tp33125975p33153338.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A different semantics for WeakMap#get default value
Brendan Eich wrote: Clearly(!) a set-if-not-present method should not be misnamed get. I like the optional sentinel-meaning-not-found for get, and setDefault per Python as Tab pointed out. Agree they should not be merged into one API. Bikeshedding setDefault at leisure (in background in my head ;-). Like: getIfAbsentSet(key, dflt) with dflt being mandatory? Still there is question of laziness of dflt, the original #get:ifAbsentPut: has the block as its second argument. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: String.prototype.[de]normalize and .isCharXxx are needed
Norbert Lindenberg wrote: Nothing planned at this point. Unicode normalization would be a natural candidate for the Globalization API, but it's not in scope for version 1. Support for Unicode character properties probably Maybe it could be added? should be part of regular expressions, as it is in Perl, PHP, Java, and other platforms; there was a proposal for ES4 [1], but it hasn't been taken up for ES5 or Harmony. Well, string comparision sans accents is a sensible use case. To do it via Unicode normalization and then removing all accents is straightforward. Should it (the character properties, however done) not be raised? [1] http://wiki.ecmascript.org/doku.php?id=proposals:extend_regexps#extending_regexps_for_unicode_ranges Norbert On Jan 3, 2012, at 4:51 , Herby Vojčík wrote: Hello, in certain application, Unicode de/normalization and possibility to query what group the character is is vital, but ECMAScript does not have these methods nor did I see them in any of the proposals? Are they planned? Or can they be added? Thanks, Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 opt-in, reloaded
On 16 January 2012 23:18, David Herman dher...@mozilla.com wrote: The goal that is missing, and what I believe is the single most important part of my New Year's email, is: 9. Allow programmers to continue thinking of JS as a single cohesive language. This is a relative concept rather than an absolute one, but it has real practical consequences on the overall cognitive complexity of the language. If you look at the terminology we've been using in TC39 for years, we either talk about multiple modes of JS, or even talk about ES6 as if it's the new language. I believe this has been a mistake. Now, we've always agreed that ES6 must necessarily subsume ES5. And you might claim that this was just imprecise and casual speech, but I think it betrays a flawed assumption: that ES6 gives us leeway to make clean breaks with the past. [...] Instead, we should hew as close as possible to an ideal of One JavaScript, knowing that we'll never be perfect. But -- I believe -- we can get pretty darn close. Thanks for that, I think we are getting to the core of our disagreement. It is kind of funny, because my goal is exactly the same, but from a different perspective. With your proposal, you give the current generation of programmers the illusion that ES6 is a simple extension of ES5. But all future programmers, who grow up with ES6 or beyond, will still have to deal with the legacy of ES5 non-strict mode. There will be two modes to worry about forever after (unless we make another breaking change). Refactoring pitfalls will persist. What I envision makes the transition somewhat more explicit for current programmers (ideally, they need to write at most one extra keyword). But anybody who starts development with ES6+ will never have to care about modes again. For her/him, extended mode is all that's relevant. Refactoring pitfalls only arise during initial version transition. I claim that on the long run, the latter will converge much closer on the ideal of One JavaScript. With your proposal, you are essentially trading perceived simplicity (which, as an aside, is factual complexity) for current JS programmers for increased complexity for all future JS programmers. You make a good point with JS code in HTML attributes, though. I don't have a good answer for that, except falling back to a meta tag. For that specific purpose, that might be fine. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 opt-in, reloaded
On 17 January 2012 03:12, David Herman dher...@mozilla.com wrote: The only way to avoid refactoring pitfalls entirely is to avoid making any changes in the language altogether. I disagree, see my previous reply. It depends on what class of refactoring pitfalls you are talking about. I believe we should do our best to avoid refactoring pitfalls as much as possible, but I can live with a few (e.g., differing scope rules for block-local functions, arguments aliasing, eval scoping, special cases for destructuring + arguments) in exchange for the drastic improvement to developers' cognitive load, the vastly improved adoption story, and the unity of the spec. I'll repeat a point I've tried to make earlier. Having all (or the majority of) new features in both classic and extended mode does _not_ decrease cognitive load, nor unity of the spec. That's an illusion (which, admittedly, may work with developers, but it's cheating on them). Instead, there are more cases everybody has to worry about. Language complexity will be _increased_, and unity of the spec is merely a euphemism for having to spec ugly corner cases that you didn't have to spec otherwise. Let me put it a different way. One lesson I've learned over years is: - context-dependent lexical syntax is a bad idea. - context-dependent grammatical syntax is a bad, bad idea. - context-dependent static semantics is a bad, bad, bad idea. - context-dependent dynamic semantics is a bad, bad, bad, bad idea. - context-dependent library semantics is... well, you get the idea... There already is enough of that in JS that we cannot get rid of. I'd prefer not to combinatorially enlarge that set. And the implicit, scoped opt-in idea is on the 4th level of badness. ;) And with that, I gonna shut up. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 opt-in, reloaded
Andreas Rossberg wrote:
On 16 January 2012 23:18, David Hermandher...@mozilla.com wrote:
The goal that is missing, and what I believe is the single most
important part of my New Year's email, is:
9. Allow programmers to continue thinking of JS as a single
cohesive language.
This is a relative concept rather than an absolute one, but it has
real practical consequences on the overall cognitive complexity of
the language. If you look at the terminology we've been using in
TC39 for years, we either talk about multiple modes of JS, or
even talk about ES6 as if it's the new language. I believe this
has been a mistake. Now, we've always agreed that ES6 must
necessarily subsume ES5. And you might claim that this was just
imprecise and casual speech, but I think it betrays a flawed
assumption: that ES6 gives us leeway to make clean breaks with the
past.
[...]
Instead, we should hew as close as possible to an ideal of One
JavaScript, knowing that we'll never be perfect. But -- I believe
-- we can get pretty darn close.
...
With your proposal, you give the current generation of programmers
the illusion that ES6 is a simple extension of ES5. But all future
programmers, who grow up with ES6 or beyond, will still have to deal
with the legacy of ES5 non-strict mode. There will be two modes to
worry about forever after (unless we make another breaking change).
Refactoring pitfalls will persist.
What I envision makes the transition somewhat more explicit for
current programmers (ideally, they need to write at most one extra
keyword). But anybody who starts development with ES6+ will never
have to care about modes again. For her/him, extended mode is all
that's relevant. Refactoring pitfalls only arise during initial
version transition.
I claim that on the long run, the latter will converge much closer
on the ideal of One JavaScript. With your proposal, you are
essentially trading perceived simplicity (which, as an aside, is
factual complexity) for current JS programmers for increased
complexity for all future JS programmers.
I agree with this. I think only a few things should be added to ES5
non-strict (destructuring, new object literal, .{...}, | {...}, maybe
something more) and one and only one opt-in to ES6 should be module
{...}, eventually use module; or similar non-bracing implicit
module-wrapper form at the beginning of program (which can be trivially
taken care by concat-builders by wrapping such program in module { ...
}; it assume the use module; form is otherwise silently ignored inside
proper module and is syntax error outside it except as a first thing in
program). Nothing else (class in ES5 non-strict is syntax error etc.)
This keeps it simple and does not force you to move to ES6 for small
useful details, only for more serious new functionality.
You make a good point with JS code in HTML attributes, though. I
don't have a good answer for that, except falling back to a meta tag.
For that specific purpose, that might be fine.
/Andreas
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 opt-in, reloaded
So I'd have to write
use version 6;
module {...}
instead of just
module {...}
even though there's no backward compatibility issue? That's just mean! :-|
Why? Assuming that modules work out, they will be in ES7,8,.. as well.
So, 'module' isn't sufficient to identify ES6. At best, 'module' identifies
ESn (n5). And that assumes that the feature will remain unchanged
for all ESns to come. I would not want to make that assumption even
for 'module', let alone for 'class'.
I like the idea of backwards compatibility, being able to run code for
the first PCs on processors design decades later. The more of that you
can pull off without cost, the better.
But not being able to throw anything away has a high cost. And I don't
think I want to give up on the idea of using ES6 to clean up some dark
corners of ES, just because someone doesn't want to have to write
'use ES6'. Client-side JS coders are already used to explicit opt-ins,
like 'doctype', to opt in to browser standard mode.
If you think (i.e., hope) that your ES6 code will work without issues
in ES7, you can leave out the 'use ES6' and let the engine choose
the current default version (if it happens to be an ES5 engine, bad
luck). If you want to document what version of ES your code is
_known_ to work with, you can use 'use ES6' (the ES7 engines
either knows how to handle that, or can give a sensible early
error/warning; ES5 engines will give a useful syntax error).
Versioning should be scoped, to reduce concatenation issues,
and the features we want put constraints on what level of version
scoping is possible/sane. Still, as a 0th approximation, one could
start with versioning to the next enclosing block/top-level, then
rule out complicated nestings of differently versioned blocks.
Versioning should also be modular: if I want to use 'yield', why
do I have to opt into all of ES6? There may be engines that support
'yield' but not yet (or no longer, or not at all) other features of ES6.
Modular/feature-based versioning would also help with your
fingers-of-fate problem: you don't want to introduce too many
changes so that coders don't get overwhelmed. But if coders
can opt in to ES6 features selectively, that is less of an issue.
So I would like to be able to say things like
use yield, let, destructuring; // opt in to specific features
use ES6;// opt in to a standard collection of features
// no explicit opt-in means implicit opt-in to
// current default version
use ES5;// explicitly opt in to an old standard, in case
// engines, standards, and defaults move on
Based on Haskell experience again, every feature/opt-in should
have its negation/opt-out, as well:
use ES6, !typeof-reform;// code will mostly work in ES6,
// but isn't ready for this feature
Fortunately, client-side JS coders have a lot of experience with
code versioning in the presence of rapidly changing feature sets,
and it is accepted best practice to do feature-testing instead of
the older practice of user-agent-version-number-testing.
So it isn't as if TC39 would have to introduce any completely
foreign ideas about versioning to JS coders - we only need to
translate the ideas into a form suitable for language feature
versioning.
Do you really think that JS coders who start their codebase with
modernizr and the like, to figure out whether the features they
want to use are supported on the engine that runs their code,
will be scared away by documenting the language features
their code relies on?
My non-speculative argument rests on experience on the web. Version
marks and other separators are mangled and lost all the time.
The point is that explicit version marks can be pointed to, and
checked against the code (your car and airplane should have
seatbelts - if not, change the dealer or airline; yes, even well
preserved old-timers are now supposed to have seatbelts; oh,
there it is, it just got mangled into that gap).
Implicit version marks use defaults, which change over time
or with context (hmm, no-one else here seems to have seat-belts,
so that must be okay?). At best, you'll have to remember what
the current defaults are and what the intended defaults were.
At worst, you'll be surprised.
Claus
http://clausreinke.github.com/
I believe we should offer well-defined script type=...;version=...
opt-in for script content hiding from old UAs, and *in addition*
belt-and-braces in-script-content version opt-in at a minimum, via some
pragma such as |use version 6;|.
The latter would also work in eval-ed code.
But I also believe these will be lost or simply not used, and adoption
will be better if we define sensible (per your arguments against
tainting from small to large extent) new-syntax-is-its-own-opt-in rules,
per Dave's o.p.
The reason I believe this is our experience in past edition shifts and
experimental extensions. Usability wins
Re: ES6 “modes” and user-friendliness
I think mode terminology is quite misleading, particularly in regard to run time semantics. For Es5 (and I believ es6) there is no need of for a global runtime mode bit that is analagous to a cpu mode bit that ambiently changes the semantics of some or all instruction. Instead, we have multiple semantic for some constructs where the appropiate semantics to use can be apriori determined based up lexical context prior to runtime. From a es programmer's perspectve it is reasonable to think about code as being in a strict context or perhaps an es6 context (a module Context?). But calling such contexts modes may create confusion, sometimes even for us. Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 “modes” and user-friendliness
Most of the extended code early errors I list in a previous message on this thread are examples of changes that are not backward compatable with Es5 strict code that Axel is talking about belowAxel Rauschmayer a...@rauschma.de wrote:Ss1. module = ES6 – some changes break with ES5.strict some changes break with ES5.strict is confusing -- do you mean 'let' works instead of being a future reserved word, whereas in (3, below) 'let' is not reserved at all? I’m not sure about specifics, I mean “ES6 things that are not backward-compatible with with ES5.strict” (if those exist, but it seems like they do). -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma Home: rauschma.de Blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Better Native XML Support
I think that requiring a user load a parser to handle XML is perfectly fine. That's the state of the art in most programming languages. On Mon, Jan 16, 2012 at 09:51, David Bruant bruan...@gmail.com wrote: Le 16/01/2012 18:30, Nuno Job a écrit : Hi guys, I would like to make the case for better native XML support in ES5: This is the most commented open issue on V8: http://code.google.com/p/v8/issues/detail?id=235 Unfortunately people didn't agree on E4X and this makes the life of developers that have to use XML miserable. While XML is not a first class citizen in the web it is the preferred interchanged format in the enterprise. Developers don't choose to use XML over JSON, they sometimes have to use XML. A solution for this would be always better if in the language. Have a look at quasis [1]. It provides what I'd consider to be a more generic and safer solution to E4X. You can send feedback to es-discuss@mozilla.org (es5-discuss is usually reserved to ECMAScript 5 specifically, though most people who are in one are certainly in both) David [1] http://wiki.ecmascript.org/doku.php?id=harmony:quasis ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
On Tue, Jan 17, 2012 at 3:34 AM, Mariusz Nowak
medikoo+mozilla@medikoo.com wrote:
James Burke-5 wrote:
This is provably false. You normally do not need hundreds of modules
to build a site.
I wasn't theorizing, I was talking about real applications that are already
produced.
What I was objecting to is the characterization that an app that loads
hundreds of module would not work and therefore builds are always
needed for all-sized apps. Finding one or two pathological cases does
not prove the need for builds for all people, and I have experience
that points otherwise, even for larger apps. Maybe you did not mean to
take the connection that far, but that is how I read it.
I think Harmony modules have more in common with CommonJS than with AMD, and
transition from CommonJS will be easier than from AMD. See slides 86-89 from
http://www.slideshare.net/medikoo/javascript-modules-done-right (it's
presentation I've done once on local Warsaw meetup)
CommonJS modules have an imperative require, that is not something
that will work in Harmony modules. AMD does not, which matches the
current harmony proposal more closely. In other words, you can do this
today in CommonJS, but this is not translatable directly to harmony
modules:
var a = require(someCondition ? 'a' : 'a1');
In the current harmony proposals, you would need to use the
callback-style of the module_loaders API to load the module. This
implies an async resolution of the dependency, which likely changes
the above module's API to the outside world.
I agree that the surface syntax of CommonJS looks more like Harmony
modules, but the transform of AMD to harmony modules is really not
that much harder, and translating from vanilla AMD modules (ones that
do not use loader plugins) does not have the kinds of conversion where
the module needs to be manually re-architected, as mentioned above.
Of course Harmony will allow you to load each module separately, but with
default syntax I understand it will work synchronously, I'm not sure we will
do that for large number of modules. For asynchronous loading you may use
dynamic loader which I think would be great to load bigger module
dependencies.
Harmony modules will parse the module code, pull out the module
dependencies, load them, do some compiling/linking, then execute the
code. This is similar to what AMD does with this form:
define(function(require) {
var a = require('a');
});
AMD loaders use Function.prototype.toString() and then parse that
function body to find the 'a' dependency, fetches and executes 'a',
then execute this function. Of course this is a bit low-tech and
having an JS engine get a real parse tree before code execution is
better. But the end behavior, as far as network traffic, is the same.
James
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
new ES6 specification draft
An updated draft is available at the usual place (http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts ) That draft incorporated decisions made at the Nov. 2011 TC39 meeting. However, note that this draft also contains a significant amount of still in flight work. Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
On 16 January 2012 14:20, Andrea Giammarchi andrea.giammar...@gmail.comwrote:
var module = require(module);
is totally fine but
require(module, function (module) {
// is totally fine too
});
latter could be synchronous in node.js and asynchronous in the web, who
cares, as long as it scales for all scenarios ... don't you agree?
One fundamental difference between how AMD modules and CommonJS modules
(presumably Node) load is that CommonJS modules have lazy initialization,
whereas AMD modules have eager initialization.
This is probably where some of the NodeAMD impedance mismatch is coming
from -- in CommonJS with Modules/1.0 on the server side, developers expect
to be able to perform certain types of initialization when the module is
loaded, and they do not expect to need to pre-declare their modules.
It will be interesting to see how the addition of ES.Next modules plays out
with the server-side JS communities.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
It's been a long time coming...
...but test262 finally standshttps://bugs.ecmascript.org/buglist.cgi?product=Test262component=Testsresolution=---list_id=777 at zero (known) invalid test cases as of an hour ago! Changeshttp://wiki.ecmascript.org/doku.php?id=test262:test_case_format contributed by Mark Miller last year supported re-enabling dozens of tests dependent upon 'this' being the global object. Also, quite a bit of time has been spent recently addressing valid test case issues. The end result of this effort is we now have 73 more tests running and 21 bugs have been resolved since the last update in November. As always, I encourage everyone to run the updated test suite against your favorite web browser to help identify any new issues with the tests, harness, or website. These can be reported at http://bugs.ecmascript.org. Again, thanks for everyone's help in making test262 great! My best, Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Better Native XML Support
David Bruant wrote: Have a look at quasis [1]. It provides what I'd consider to be a more generic and safer solution to E4X. E4X is more than just data production, though. It added a number of accessors/syntax for handling XML elements, many of which can be the LHS of an assignment: expr..ident // descendant selection expr.@ident // attribute selection expr.* // All-children selection expr.(filter) // Filtering a set, with an implicit 'with' @ident // At least within a filter, attribute selection expr.var::ident // Using the namespace in var, descendant selection In combination, they provide some concise ways of manipulating document-free XML nodes, though with large number of downsides that probably aren't worth covering in detail, here. It might be worth considering bringing some of those constructs back in a more generic and future-proof fashion in future versions of ECMAScript. Or it might instead be worth considering allowing quasis to be the LHS of an assignment, which would be useful and could then cover more e4x use cases. (I've removed es5-discuss from the recipients, since this is no longer relevant to that) Regards, Grant Husbands. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Better Native XML Support
If you desperately need it, you should be able to make a library for it, and then if you need the extra syntax, add an extra compile step - like what coffeescript does. After all, e4x is just an extension to JS, it should be possible to add the data types natively and then make any e4x code work as syntactic sugar, which you can desugar yourself. I'm not saying its an insignificant effort, but it seems fairly straightforward. The standardized grammar for it is defined as an extension to Ecmascript after all. - Russ On Tue, Jan 17, 2012 at 12:57 PM, Grant Husbands esdisc...@grant.x43.netwrote: David Bruant wrote: Have a look at quasis [1]. It provides what I'd consider to be a more generic and safer solution to E4X. E4X is more than just data production, though. It added a number of accessors/syntax for handling XML elements, many of which can be the LHS of an assignment: expr..ident // descendant selection expr.@ident // attribute selection expr.* // All-children selection expr.(filter) // Filtering a set, with an implicit 'with' @ident // At least within a filter, attribute selection expr.var::ident // Using the namespace in var, descendant selection In combination, they provide some concise ways of manipulating document-free XML nodes, though with large number of downsides that probably aren't worth covering in detail, here. It might be worth considering bringing some of those constructs back in a more generic and future-proof fashion in future versions of ECMAScript. Or it might instead be worth considering allowing quasis to be the LHS of an assignment, which would be useful and could then cover more e4x use cases. (I've removed es5-discuss from the recipients, since this is no longer relevant to that) Regards, Grant Husbands. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A different semantics for WeakMap#get default value
On Jan 17, 2012, at 3:45 AM, Herby Vojčík wrote:
Brendan Eich wrote:
Clearly(!) a set-if-not-present method should not be misnamed get.
I like the optional sentinel-meaning-not-found for get, and setDefault
per Python as Tab pointed out. Agree they should not be merged into one
API. Bikeshedding setDefault at leisure (in background in my head ;-).
Like:
getIfAbsentSet(key, dflt)
with dflt being mandatory?
Still there is question of laziness of dflt, the original #get:ifAbsentPut:
has the block as its second argument.
The Smalltalk solution to this problem is the
at: key ifAbsent: block
method.
This subsumes both get with default value and get create if missing use cases
plus others. In JS we might say:
col.getIfAbsent(key) {|| 42}; //use 42 if no present
col.getIfAbsent(key) {|| col.defaultValue}; //have collection provide the
default value
col.getIfAbsent(key) {|| col.put(key, 42); 42} //if key isn't there add it
with an appropriate vaue
Allen
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block Lambdas: break and continue
Allen Wirfs-Brock wrote:
do: arr.alternate ({|o| if (...) continue; if (...) break; ...}, {|o| if
(...) continue; ...});
I don't see how this can support the most likely intended semantics
I think others might have better answers, but it seems that the
meaning of 'break' is to stop the whole statement, and the meaning of
'continue' is to skip the inner block and hence return to
arr.alternate. I'm sorry for my woolly language, but it seems
relatively equivalent to a for loop, in which 'break' stops the whole
statement and 'continue' skips the inner block and hence returns to
the looping code.
Perhaps what I'm saying is that I think do: is a label for the whole
callexpression, covering all lambda-block parameters. As far as the
specification goes, a continue that 'hits' the block lambda may well
be best described as a local return.
Or I might be misreading.
Regards,
Grant Husbands.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Globalization API holiday summary
On Jan 16, 2012, at 7:45 PM, Norbert Lindenberg wrote: On Dec 8, 2011, at 10:25 , Nebojša Ćirić wrote: Proposed changes to the original API: [snip] 2a. What happens with toLocaleString methods when user doesn't load @globalization module? I think they should work as specified in the Globalization API spec regardless. You don't want to get different results from these methods depending on whether some component on the page has loaded the module or none has. What about backwards compatibility? Some pages may be doing browser sniffing to customize themselves for the current implementation dependent behavior of toLocaleString and friends. For this reason, continuing to specify the behavior as implementation defined in the absence of loading the @globalization module may be a reasonable alternative Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Better Native XML Support
On 17 January 2012 13:05, Russell Leggett russell.legg...@gmail.com wrote: After all, e4x is just an extension to JS, it should be possible to add the data types natively and then make any e4x code work as syntactic sugar, which you can desugar yourself. I don't really know the details, but that is definitely not true. Ask Jeff Walden from Mozilla for details, if you can convince him to discuss the topic. :) This may be true for something approaching E4X, and might be a great way to approach the community's needs. An XML library and a pre-processor. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A different semantics for WeakMap#get default value
Allen Wirfs-Brock wrote:
On Jan 17, 2012, at 3:45 AM, Herby Vojčík wrote:
Brendan Eich wrote:
Clearly(!) a set-if-not-present method should not be misnamed
get.
I like the optional sentinel-meaning-not-found for get, and
setDefault per Python as Tab pointed out. Agree they should not
be merged into one API. Bikeshedding setDefault at leisure (in
background in my head ;-).
Like: getIfAbsentSet(key, dflt) with dflt being mandatory? Still
there is question of laziness of dflt, the original
#get:ifAbsentPut: has the block as its second argument.
The Smalltalk solution to this problem is the at: key ifAbsent:
block method.
There is also
at: key ifAbsentPut: block
At least in Squeak it was there.
This subsumes both get with default value and get create if missing
use cases plus others. In JS we might say:
col.getIfAbsent(key) {|| 42}; //use 42 if no present
col.getIfAbsent(key) {|| col.defaultValue}; //have collection
provide the default value
col.getIfAbsent(key) {|| col.put(key, 42); 42} //if key isn't there
add it with an appropriate vaue
except it computes collection twice. If it is something like:
foo.bar().getIfAbsent(key) {|| foo.bar().put(key, 42); 42}
it is a bit clumsy. You can pass the collection itself in an argument
foo.bar().getIfAbsent(key) {|c| c.put(key, 42); 42}
but you have the same problem with value, if it is computed, you must
foo.bar().getIfAbsent(key) {|c| let v = baz(); c.put(key, v); v}
so it seems better to have different api and write
foo.bar().getIfAbsentSet(key) {|| baz()}
Also, Mark S. Miller wrote:
As it is now, I can give someone a read-only view of a WeakMap wm my
simply giving them
{ get: wm.get.bind(wm), has: wm.has.bind(wm) }
so distinct API is for writeback version is probably not a bad idea.
Allen
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Better Native XML Support
On Tue, Jan 17, 2012 at 1:30 PM, Grant Husbands esdisc...@grant.x43.netwrote: Russell Leggett wrote: If you desperately need it, you should be able to make a library for it, and then if you need the extra syntax, add an extra compile step I was simply making sure everyone was on the same page as regards e4x and was making suggestions to try to bridge the gap. I don't need it myself, though I imagine the you there wasn't necessarily aimed at me. Yeah, not directed at you. Couldn't remember how the thread started. You seemed to be an advocate so that's where I went with it. Sorry. I'm not saying its an insignificant effort, but it seems fairly straightforward. The standardized grammar for it is defined as an extension to Ecmascript after all. Though source to source processors are a source of significant friction (complicating build and debug), this would indeed be something for the community of e4x supporters to consider. Hopefully, the right people will see this thread. It is a source of friction, but its also extremely commonplace now. I imagine something like an e4x pre-processor would output code that was pretty easy to debug as well, and it sounds like we'll be seeing source mapped debuggers soon enough. I think that assignment into quasis may yet be useful, but perhaps it doesn't belong in this thread. Regards, Grant Husbands. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 opt-in, reloaded
Andreas Rossberg January 17, 2012 4:49 AM On 16 January 2012 19:35, Brendan Eich bren...@mozilla.org wrote: new ES6 features to classic mode, as has been proposed by several people, clearly works against (3), I object. 3 is misstated to assume "switching" means all-or-nothing. If ES6 has new features and they are worth using, developers will want to use them piecewise and conveniently. Assuming they will do so at the price of a leading "use version 6" or equivalent pragma is debatable. We shouldn't just assume this conclusion. OK. But that sounds like a clear departure from the "ES.next/Harmony is based on strict mode" axiom that everybody seemed to have agreed on long ago. Do we have consensus on abandoning that goal? (Thus my description as "backporting".) It's not quite the departure you might think. E.g. destructuring formal parameters piggy-backs on strict mode logic to forbid duplicates anywhere in the parameter list. More below. and consequently, also against (5/6). This does not follow. Users transitioning to use new features may be helped, not hindered, by we spec and implementation editors working harder. In particular allowing, e.g., destructuring in non-strict code may be boon to developers, whereas requiring them to maintain explicit opt-in pragmas before doing so simply to convenience spec editors and implementors may be a global loss. Adding new features to both modes is almost guaranteed to lead to new items to the list of non-strict vs. strict mode differences. That implies new refactoring risks. I don't see a way around that. I do. We have strict mode changes, both early errors and runtime changes in meaning. For the early errors, we piggy-back to make new syntax in non-strict code trigger the same error, as with the destructuring parameters example above. For runtime shifts in meaning, we can still piggy-back if the change is "enclosed" by the new syntax. What do I mean by enclosed? Consider destructuring parameters. Should they trigger strict arguments object semantics, a runtime shift? No, the destructuring pattern in one formal parameter does not enclose the whole parameter list, or body uses of arguments. So what should arguments semantics be? Non-strict. Why isn't this a problem? Because destructuring parameters have no named formal for the whole object passed as the actual and destructured by the pattern. There's no need to alias, and we do not want deep-aliasing, ever (we = users, implementors). Is this split between enabling early strict-like errors for duplicates, but not triggering strict arguments, a refactoring risk? I don't know. I think we should look at it. It could be a risk, certainly -- but it may be tiny. Similarly, opting in at smaller scope, as has also been discussed, is a blatant violation of (6) and (7), and works against (3), too. Let's agree, based on your earlier arguments and also on Dave's point that lexical scope (free variable error analysis) won't work if opt-in is too local. OK, I'm really glad. :) See, toldya es-discuss is not scary ;-). Meanwhile, JS1 grew via ES1-5 and various implementations (SpiderMonkey and Rhino) without any such opt-in, *except* for two keywords we couldn't reserve (and some incompatible change attempts that failed, vs. goal 8 -- one example: I tried to make == and != strict in JS1.2 to get ES1 to switch, but that broke the web, wherefore === and !==). Doesn't that kind of make my point? Breaking changes, even small, need opt-in. No, JS1.2 with its version (via the old language="_javascript_1.2" attribute, remember that) failed. ES1 changed JS de-facto standards without opt-in. Same for ES2 and 3. We supported versioning via language= and later type= but it was hardly used outside of Mozilla-specific JS. Developers do not want version opt-in, certainly not as a requirement. One JS. Have to stop here, out of time. Please feel free to reply to anything, I hope I didn't miss something later in your message that invalidates what I wrote in this message! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Unblocking sleep semantics
More material: http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web/ On Jan 17, 2012, at 21:30 , Dean Landolt wrote: You can get these semantics with generators plus a library (see Dave Herman's task.js [1] as a great example). As generators your `return function;` special form would be spelled spelled `yield` instead, and as shallow continuations this style avoids the potential interleaving hazards implied by your proposal (the inherent run-to-completion violation of fibers). [1] https://github.com/mozilla/task.js -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Unblocking sleep semantics
Le 17/01/2012 21:38, Axel Rauschmayer a écrit : More material: http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web/ ... and a link to the proposal: http://wiki.ecmascript.org/doku.php?id=harmony:generators ;-) David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Unblocking sleep semantics
On Tue, Jan 17, 2012 at 3:54 PM, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote: Yeah, I was aware of the coroutines in generators, that's why I said it would be sort of sugar. :) But it's not sugar, it's a different feature. It's the difference between shallow and deep continuations. We already have shallow continuations (by way of generators). Deep continuations are potentially hazardous. I for one would love some sugar for the shallow continuations use-case of generators but libraries will do just fine. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Unblocking sleep semantics
Okay, now that I've been re-reading how generators work and about task.js, it has made me realize my error. Yes, you're right, what I've made is actually deep continuations, and that's not really what I had in mind. Thanks everyone, I'll try to think of a better way to do this (or to find out if it already exists :] ). Cheers, Jussi On Tue, Jan 17, 2012 at 11:00 PM, Dean Landolt d...@deanlandolt.com wrote: On Tue, Jan 17, 2012 at 3:54 PM, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote: Yeah, I was aware of the coroutines in generators, that's why I said it would be sort of sugar. :) But it's not sugar, it's a different feature. It's the difference between shallow and deep continuations. We already have shallow continuations (by way of generators). Deep continuations are potentially hazardous. I for one would love some sugar for the shallow continuations use-case of generators but libraries will do just fine. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: new ES6 specification draft
Allen Wirfs-Brock wrote:
An updated draft is available at the usual place
(http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts )
That draft incorporated decisions made at the Nov. 2011 TC39 meeting.
However, note that this draft also contains a significant amount of
still in flight work.
Allen
PropertyAssignment : PropertyName ( FormalParameterList ) { FunctionBody }
1. Let propName be PropName of PropertyName.
2. Let closure be the result of creating a new Function object as
specified in 13.2 using a FormalParameterList : [empty] production as
the parameter list and body specified by FunctionBody. Pass in the
LexicalEnvironment of the running execution context as the Scope. Pass
in true as the Strict flag. Pass object as the optional homeObject
argument and propName as the optional methodName argument.
3. Let desc be the Property Descriptor{[[Get]]: closure, [[Enumerable]]:
true, [[Configurable]]: true}
4. Call the [[DefineOwnProperty]] internal method of object with
arguments propName, desc, and false.
is just a copy-pasted getter (which is after this and has 5. - 8.
instead 1. - 4.). 3. should be changed to
3. Let desc be the Property Descriptor{[[Value]]: closure,
[[Enumerable]]: false, [[Configurable]]: true, [[Writable]]: true}
probably.
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block Lambdas: break and continue
Axel Rauschmayer January 17, 2012 1:04 AM Minor possibility of future-hostility: Should real keyword arguments ever make it to ECMAScript, labels such as "do:" seem an obvious choice. No, JS doesn't allow reserved identifiers to be used as parameter names in any case. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block Lambdas: break and continue
Grant Husbands January 17, 2012 10:14 AM I think others might have better answers, but it seems that themeaning of 'break' is to stop the whole statement, and the meaning of'continue' is to skip the inner block and hence return toarr.alternate That's what I was thinking too. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: String.prototype.[de]normalize and .isCharXxx are needed
In order to get version 1 of the Globalization API done and into the hands of users, we're no longer considering new functionality for this version. On the other hand, string comparison (collation) is already included in this version, and the sensitivity option lets you choose whether it should be sensitive to minor differences such as accents. See http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts http://norbertlindenberg.com/2011/11/ecmascript-globalization-api/index.html Norbert On Jan 17, 2012, at 4:06 , Herby Vojčík wrote: Norbert Lindenberg wrote: Nothing planned at this point. Unicode normalization would be a natural candidate for the Globalization API, but it's not in scope for version 1. Support for Unicode character properties probably Maybe it could be added? should be part of regular expressions, as it is in Perl, PHP, Java, and other platforms; there was a proposal for ES4 [1], but it hasn't been taken up for ES5 or Harmony. Well, string comparision sans accents is a sensible use case. To do it via Unicode normalization and then removing all accents is straightforward. Should it (the character properties, however done) not be raised? [1] http://wiki.ecmascript.org/doku.php?id=proposals:extend_regexps#extending_regexps_for_unicode_ranges Norbert On Jan 3, 2012, at 4:51 , Herby Vojčík wrote: Hello, in certain application, Unicode de/normalization and possibility to query what group the character is is vital, but ECMAScript does not have these methods nor did I see them in any of the proposals? Are they planned? Or can they be added? Thanks, Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block Lambdas: break and continue
On Jan 17, 2012, at 10:14 AM, Grant Husbands wrote:
Allen Wirfs-Brock wrote:
do: arr.alternate ({|o| if (...) continue; if (...) break; ...}, {|o| if
(...) continue; ...});
I don't see how this can support the most likely intended semantics
I think others might have better answers, but it seems that the
meaning of 'break' is to stop the whole statement, and the meaning of
'continue' is to skip the inner block and hence return to
arr.alternate. I'm sorry for my woolly language, but it seems
relatively equivalent to a for loop, in which 'break' stops the whole
statement and 'continue' skips the inner block and hence returns to
the looping code.
Yes, that was the intended meaning I was trying to express. But what I was
illustrating was that for this to work a continue wihout a target label and an
equivalently located break without a target label need to unwind to different
points in the enclosing nesting structure. This seems different (perhaps
surprisingly so) from equivalent continue/breaks nested only within blocks and
an IterationStatement. But that is the semantics that are need to fulfill my
intent is this particular case. Maybe this generalizes to all use reasonable
cases, but it something about it makes me feel a bit uncomfortable.
Perhaps what I'm saying is that I think do: is a label for the whole
callexpression, covering all lambda-block parameters. As far as the
specification goes, a continue that 'hits' the block lambda may well
be best described as a local return.
Yes, this seems about right. But can this behavior for break/continue be
explained in a way that doesn't seems arbitrarily different from
break/continue in the context of IterationStatements and regular blocks.
Perhaps we can describe a general transformation that converts an
IterationStatement to/from an equivalent call to an iteration function with
block lambda arguments.
Allen
Or I might be misreading.
Regards,
Grant Husbands.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ES6 Collections Polyfill
Somebody may be interested into ES6 Map, WeakMap, and Set Here my attempt with all explanations: https://github.com/WebReflection/es6-collections The code must work in every browser/JS engine, reasons about weakness choice listed too. Now you know, feedbacks welcome br ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
