This These feature--most of them-- would be something I see in the browser
api... This is truly looking like w3c working group...
... But I don't see any chance of my words changing the direction of the
spec Especially when you consider the original designer of the language
steering
I don't see why you're complaining. If you don't like the features in ES6,
then just don't use them. The features of ES5 are still available.
If you want to have more strict code, then add a use strict; statement to
your code.
And if you're against adding more features to the core language, then
Yeah I guess I'm pretty late for that huh... No this is great, the more
feature, the better. A lot of these feature would cause certain application not
to be needed... In other words, use more of the language and less libraries
Why you at it, how about reviving E4X? That way, we can
Hi L2L, this message is uninformed that I must ask you to move to another
forum, until you learn a lot more about js and web programming. This is not
the place.
On Sep 10, 2014 6:47 AM, L2L 2L emanuelal...@hotmail.com wrote:
Yeah I guess I'm pretty late for that huh... No this is great, the
Meant this message is so uninformed that
On Sep 10, 2014 6:55 AM, Mark S. Miller erig...@google.com wrote:
Hi L2L, this message is uninformed that I must ask you to move to another
forum, until you learn a lot more about js and web programming. This is not
the place.
On Sep 10, 2014 6:47
Axel Rauschmayer wrote:
Now is second half of 2014, and lots of issues are not closed yet,
from what I see.
The spec already looks pretty complete to me and Traceur and TypeScript
do a pretty good job of letting you use ES6 today.
As previously announced here, the current schedule is to be
I think you are confusing the internal spec function from the API function
deliverChangeRecords.
Object.deliverChangeRecords always returns undefined. It is the internal
[[DeliverChangeRecords]] that gets called until the queue of change records
is exhausted.
The point of
For or loops are spec'ed to call the internal spec function, IteratorClose
when there is an abrupt completion in the loop body (an exception was
thrown, return and break)
The point of this was to allow cleaning up the iterator in case it holds on
to some kind of resource.
The problem is that
On Wed, Sep 10, 2014 at 7:45 AM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
For or loops are spec'ed to call the internal spec function, IteratorClose
when there is an abrupt completion in the loop body (an exception was
thrown, return and break)
The point of this was to allow cleaning
On 10 September 2014 16:45, Erik Arvidsson erik.arvids...@gmail.com wrote:
For or loops are spec'ed to call the internal spec function, IteratorClose
when there is an abrupt completion in the loop body (an exception was
thrown, return and break)
The point of this was to allow cleaning up the
On 10 September 2014 16:52, Mark S. Miller erig...@google.com wrote:
On Wed, Sep 10, 2014 at 7:45 AM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
I see two options here.
1. Add IteratorClose to all places in the spec where we use iterators.
Why was #1 rejected? I just don't remember.
I
As previously announced here, the current schedule is to be finished by
the end of the year, to start the publication process in March 2014 and
to have a standard by June 2014.
They already happened. Did you mean 2015?
Yes I did!
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
Reading your explanation and rereading the change notes at
http://wiki.ecmascript.org/doku.php?id=harmony:observe (need to learn to
look there more) I see how this change came to be.
Time for a minor hack to get it in and then some major rewriting to support
it properly along with other changes
This sounds to me like it just need to be reported as a bug There have been
previous bugs that have identified places where library methods iterated in a
manner that precluded implementing them via for-of. For example
https://bugs.ecmascript.org/show_bug.cgi?id=2083 Those bugs were all fixed.
Hi Allen, does that mean we agreed to the equivalent of Arv's #1? If so,
great!
On Wed, Sep 10, 2014 at 8:25 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
This sounds to me like it just need to be reported as a bug There have
been previous bugs that have identified places where library
A couple of months ago I tried out the suggestion by Yehuda Katz to use
import syntax with special module specifiers to mean parse-as-script, do
evaluate but do not produce a module. The implementation worked well and
now I want to put a version of this idea into Traceur.
As soon as I started I
This L2L2L2 person has been trolling JS channels on freenode for the last
few days, suggest ignoring them.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I actually started believing @horse_esdiscuss left twitter to rant freely
in here ... although I'm having hard time judging if there's simply a huge
language barrier that might make it easy to misunderstand tone and intent.
Emanuel I hope you are OK with answers you got also because there's not
Personally I have felt this way for a long time as well. I think `.esm` is
somewhat confusing since most js developers don't really think about it as
EcmaScript. I would think you could just as easily do `.jsm` but this also
suggests that files of this alternate should be served with a different
On Sep 10, 2014, at 8:29 AM, Mark S. Miller wrote:
Hi Allen, does that mean we agreed to the equivalent of Arv's #1? If so,
great!
We agree at our June meeting to add the return method to generators and to
conditionally call return (if it is present) when a for-of loop terminates
before it
On 10 September 2014 17:56, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
We agree at our June meeting to add the return method to generators and to
conditionally call return (if it is present) when a for-of loop terminates
before it exhausts its generator. See
Matthew Robb wrote:
Personally I have felt this way for a long time as well. I think
`.esm` is somewhat confusing since most js developers don't really
think about it as EcmaScript.
(sounds like a skin disease...)
I would think you could just as easily do `.jsm` but this also
suggests that
On Wed, Sep 10, 2014 at 6:14 PM, Brendan Eich bren...@mozilla.org wrote:
RFC4329 rightly favors application/ -- but this is all beyond the scope of
ECMA-262. Do Not Want TC39 deciding suffixes. Let developers develop
conventions. (Just so long as they do not sound like skin diseases.)
Well the
On Sep 10, 2014, at 8:44 AM, Matthew Robb wrote:
Personally I have felt this way for a long time as well. I think `.esm` is
somewhat confusing since most js developers don't really think about it as
EcmaScript. I would think you could just as easily do `.jsm` but this also
suggests that
On Wed, Sep 10, 2014 at 12:20 PM, Anne van Kesteren ann...@annevk.nl
wrote:
(I think text/javascript is just fine btw. text/* works great for HTML
and CSS too. In any event, for the purposes of the browser JavaScript
does not really have a MIME type. We parse anything we get...)
The
On Wed, Sep 10, 2014 at 6:23 PM, Matthew Robb matthewwr...@gmail.com wrote:
The problem is that there are now two distinctly different types of
javascript file, some should be parsed as script and some should be parsed
as module. Assuming everything is script that is not explicitly module would
Well the default browser loader which is still secret(?) purportedly
standardizes on a js suffix. That is probably why this came up.
My understanding is that we have backed off from automagically appending
.js to relative paths, but that info could be old.
As soon as the language decided it would have a differentiation for modules
vs scripts then it seems only natural that it should also specify at least
some generic means of entry into one mode or another. Then it's up to
browsers or who ever to determine what external signifiers would trigger
On Sep 10, 2014, at 9:00 AM, Andreas Rossberg wrote:
On 10 September 2014 17:56, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
We agree at our June meeting to add the return method to generators and to
conditionally call return (if it is present) when a for-of loop terminates
before it
On Sep 10, 2014, at 9:28 AM, Matthew Robb wrote:
As soon as the language decided it would have a differentiation for modules
vs scripts then it seems only natural that it should also specify at least
some generic means of entry into one mode or another. Then it's up to
browsers or who
Modules and scripts can not always be identified by inspection. Consider:
foo.js ---
const answer = 42;
---
The semantics of this are quite different depending upon whether foo.js is
evaluated as a script or loaded as a
On Wed, Sep 10, 2014 at 9:35 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 10, 2014, at 9:28 AM, Matthew Robb wrote:
As soon as the language decided it would have a differentiation for
modules vs scripts then it seems only natural that it should also specify
at least some
Alternatively you could argue that some of the hooks in Loader shouldn't be
in the language spec because they should likely exist outside of something
that is hyper-specifically a module loader. So if the web has a resource
loader construct similar to ES6 Loader and it would handle resolving paths
On Sep 10, 2014, at 12:23, Matthew Robb matthewwr...@gmail.com wrote:
On Wed, Sep 10, 2014 at 12:20 PM, Anne van Kesteren ann...@annevk.nl wrote:
(I think text/javascript is just fine btw. text/* works great for HTML
and CSS too. In any event, for the purposes of the browser JavaScript
On Sep 10, 2014, at 12:35, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Sep 10, 2014, at 9:28 AM, Matthew Robb wrote:
As soon as the language decided it would have a differentiation for modules
vs scripts then it seems only natural that it should also specify at least
some
There are numerous discussions about this throughout the last two years and
you can find record of them throughout es-discuss. Someone closer to the
topic can likely fill you in but I won't try to pull that information off
the top of my head.
- Matthew Robb
On Wed, Sep 10, 2014 at 12:53 PM,
But why?
To be completely serious. Why do we have to make a difference?
Because we have implicit module bodies, which have different
variable-scoping and strict-mode semantics than regular scripts. The
alternative would have been boilerplate in every module forever.
Some info was discussed here: http://esdiscuss.org/notes/2014-01-28
- Matthew Robb
On Wed, Sep 10, 2014 at 12:53 PM, Todd Kennedy t...@selfassembled.org
wrote:
On Sep 10, 2014, at 12:35, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 10, 2014, at 9:28 AM, Matthew Robb wrote:
As
On Sep 10, 2014, at 9:41 AM, John Barton wrote:
On Wed, Sep 10, 2014 at 9:35 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 10, 2014, at 9:28 AM, Matthew Robb wrote:
As soon as the language decided it would have a differentiation for modules
vs scripts then it seems
Yeah heres a bit more in depth discussion on the topic:
http://esdiscuss.org/topic/detecting-js-language-mode-for-tools#content-12
- Matthew Robb
On Wed, Sep 10, 2014 at 12:53 PM, Todd Kennedy t...@selfassembled.org
wrote:
On Sep 10, 2014, at 12:35, Allen Wirfs-Brock al...@wirfs-brock.com
On 9/10/14, 10:45 AM, Erik Arvidsson wrote:
1. Add IteratorClose to all places in the spec where we use iterators.
And other specs (e.g. Web IDL) that use iterators, right?
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
The question of whether a file is a module or script is the same problem as
to whether a module is ES6 or AMD or CommonJS.
Moving it to the extension makes as much sense as having every CommonJS
module written as `script.cjs`.
We know that we need outside metadata to work out how to interpret
So my thought based on this comment:
http://esdiscuss.org/topic/detecting-js-language-mode-for-tools#content-14
Why not deprecate sloppy-script mode explicitly and encourage the movement
to module-strict for all scripts moving forward. Once you do that then you
can make the decision to spec the
On Wed, Sep 10, 2014 at 10:07 AM, Guy Bedford guybedf...@gmail.com wrote:
The question of whether a file is a module or script is the same problem
as to whether a module is ES6 or AMD or CommonJS.
Moving it to the extension makes as much sense as having every CommonJS
module written as
In NodeJS, this can be through `package.json` properties which inform what
module format the package is.
Right - although having a runtime system looking at json config files is a
terrible idea. : ) In es6now, I'm experimenting with the following rule:
- If some folder that might be a
Boil the ocean schemes never work, especially not on the Web. Indeed
Allen's use of dream to describe the hope that in the far future
everything is module code is not unfair. Dreams do come true, but only
incrementally where there's local advantage.
Saw your followup to my Nope-topus post.
You want aggressive common sub-expression elimination on the specs (all
of them, as bz noted).
Is there a common helper spec-only method that can be used both inside
ES6 and by other specs?
Allen Wirfs-Brock wrote:
Yes, except that I don't think the body of those loops can actually
I don't see why they have to? Traceur should be used as a build time tool
that ultimately runs in legacy mode. Only REAL modern ES6 module
implementations would run in this other world. Basically .es files today
would be transpiled into .js files.
- Matthew Robb
On Wed, Sep 10, 2014 at 1:22 PM,
On Sep 10, 2014, at 10:07 AM, Boris Zbarsky wrote:
On 9/10/14, 10:45 AM, Erik Arvidsson wrote:
1. Add IteratorClose to all places in the spec where we use iterators.
And other specs (e.g. Web IDL) that use iterators, right?
Right, or come up with some other way to say: this loop behaves as
Matthew Robb wrote:
I don't see why they have to? Traceur should be used as a build time
tool that ultimately runs in legacy mode. Only REAL modern ES6 module
implementations would run in this other world. Basically .es files
today would be transpiled into .js files.
I doubt people will do
On Sep 10, 2014, at 10:24 AM, Brendan Eich wrote:
You want aggressive common sub-expression elimination on the specs (all of
them, as bz noted).
Is there a common helper spec-only method that can be used both inside ES6
and by other specs?
Not yet. Probably should be, but I have to
On 9/10/14, 1:28 PM, Allen Wirfs-Brock wrote:
Right, or come up with some other way to say: this loop behaves as if it was
implemented using for-of.
Thing is, for my Web IDL use case I don't want _quite_ the behavior of
for-of. I want something like this:
1. Let method be the result of
I just think the idea of 1JS has already been compromised and really what
we have is a spec that supports two almost-entirely different sets of
expectations. The maintenance of keeping them of equal priority seems like
it will only get worse over time. The `use strict` pragma is already sort
of an
On Sep 10, 2014, at 10:33 AM, Brendan Eich wrote:
Tools will have to read metadata, tea-leaves, and etheric winds to keep up.
Same as ever.
And humans. When scanning a big directly of js files it's going to be real
useful for code readers to be able to quickly identify what they are
On Sep 10, 2014, at 10:37 AM, Boris Zbarsky wrote:
On 9/10/14, 1:28 PM, Allen Wirfs-Brock wrote:
Right, or come up with some other way to say: this loop behaves as if it
was implemented using for-of.
Thing is, for my Web IDL use case I don't want _quite_ the behavior of
for-of. I want
I was trying to... Leave it alone. But I'm seeing people speak on it and most
importantly of me :-(.
For those who speak ugly toward me, you don't have to speak at all.
Abs for the rest... The two people who seem to be against this, and who are
running this spec have spoken
So there is
On 10 September 2014 19:23, Kevin Smith zenpars...@gmail.com wrote:
In NodeJS, this can be through `package.json` properties which inform
what module format the package is.
Right - although having a runtime system looking at json config files is a
terrible idea. : ) In es6now, I'm
Should we have new type - tuples?
My proposal:
- Tuples are immutable.
Eg.
var wow = new Tuple('my', 'little', 'Cthulhu');
wow[2] = 'Nyarlathotep'; // throws in strict mode, silently fails in sloppy mode
- Tuples are primitive type. Comparison between tuples is based on
identity of elements, not
On 9/10/14, 1:47 PM, Allen Wirfs-Brock wrote:
1. Let method be the result of CheckIterable(V).
2. ReturnIfAbrupt(method).
3. If IsCallable(method) is false, go off and do something else,
since V is not iterable.
4. Let iter be GetIterator(V, method).
5. ReturnIfAbrupt(iter).
and then
On Wed, Sep 10, 2014 at 8:17 AM, Alexandre Morgaut alexandre.morg...@4d.com
wrote:
Hi,
The way this discussion started looked very troll oriented, but let
comment few things I more or less agree or not with
What I see is more functionality of the browser api then an actually
language.
E-S4L
N-S4L
On Sep 10, 2014, at 12:14 PM, Brendan Eich bren...@mozilla.org wrote:
Matthew Robb wrote:
Personally I have felt this way for a long time as well. I think `.esm` is
somewhat confusing since most js developers don't really think about it as
EcmaScript.
(sounds like a skin
On 10 September 2014 19:18, John Barton johnjbar...@google.com wrote:
On Wed, Sep 10, 2014 at 10:07 AM, Guy Bedford guybedf...@gmail.com
wrote:
The question of whether a file is a module or script is the same problem
as to whether a module is ES6 or AMD or CommonJS.
Moving it to the
On Wed, Sep 10, 2014 at 10:40 AM, Matthew Robb matthewwr...@gmail.com
wrote:
I just think the idea of 1JS has already been compromised and really what
we have is a spec that supports two almost-entirely different sets of
expectations. The maintenance of keeping them of equal priority seems
Rick Waldron wrote:
On Wed, Sep 10, 2014 at 10:40 AM, Matthew Robb matthewwr...@gmail.com
mailto:matthewwr...@gmail.com wrote:
I just think the idea of 1JS has already been compromised and
really what we have is a spec that supports two almost-entirely
different sets of
But if the goal is for everything going forward to use the scope
environment characteristics of modules (strict-mode and local-global) then
why not specify that and move the old model to a legacy mode. This just
shifts all existing implementations to be compliant with legacy mode but
not yet
On Wed, Sep 10, 2014 at 11:02 AM, Guy Bedford guybedf...@gmail.com wrote:
On 10 September 2014 19:18, John Barton johnjbar...@google.com wrote:
In NodeJS, this can be through `package.json` properties which inform
what module format the package is. In the browser, this could be a header,
or
Matthew Robb wrote:
But if the goal is for everything going forward to use the scope
environment characteristics of modules (strict-mode and local-global)
then why not specify that and move the old model to a legacy mode.
What old model? There's one spec. We are not forking specs. Engines
E-S4L
N-S4L
On Sep 10, 2014, at 2:13 PM, Matthew Robb matthewwr...@gmail.com wrote:
But if the goal is for everything going forward to use the scope environment
characteristics of modules (strict-mode and local-global) then why not
specify that and move the old model to a legacy mode.
I don't think it should have anything to do with modules though. It's a
fundamental change in the scoping/execution mechanics of any new script
compiled into a running environment. Previously new code compiled and run
would execute with global scope and sloppy mode. My suggestion is a pragma
you
Why would tuples be any more memory efficient than objects or arrays?
On 10 Sep 2014 11:57, Michał Wadas michalwa...@gmail.com wrote:
Should we have new type - tuples?
My proposal:
- Tuples are immutable.
Eg.
var wow = new Tuple('my', 'little', 'Cthulhu');
wow[2] = 'Nyarlathotep'; //
But within that you would also need a distinction of CommonJS or global as
well?
One way might be to set up configuration to know which module names are of
which format:
```
System.metadata['test/*'] = {
format: 'global'
};
System.metadata['src/node/*'] = {
format: 'cjs'
}
```
Of course
I don't see how this is not forking:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-scripts-and-modules
There are now two distinctly different models and yes they both work in the
same VM simultaneously but that's not what authors would care about.
Personally I want
I'd prefer the heading be Scripts and LegacyScripts. Just so happens that
the module features are only available in Scripts.
- Matthew Robb
On Wed, Sep 10, 2014 at 2:28 PM, Matthew Robb matthewwr...@gmail.com
wrote:
I don't see how this is not forking:
Why would it be a terrible idea to read the package.json as part of a
server-based import mechanism?
Architecturally, it should be possible to write self-describing programs.
Configuration files are good for tools (e.g. package managers and
compilers) and application settings.
Node
Here's the idea, in full:
https://github.com/zenparsing/es6now/blob/master/docs/modules.md
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Sep 10, 2014, at 10:58 AM, Boris Zbarsky wrote:
On 9/10/14, 1:47 PM, Allen Wirfs-Brock wrote:
1. Let method be the result of CheckIterable(V).
2. ReturnIfAbrupt(method).
3. If IsCallable(method) is false, go off and do something else,
since V is not iterable.
4. Let iter be
On 9/10/14, 3:20 PM, Allen Wirfs-Brock wrote:
why wouldn't a self-hoster just continue with:
for (let next of iter} {
/* body */
}
I feel like I'm missing something here.
iter is an iterator, not an iterable. So I don't think this will do
the right thing, unless I'm seriously
On Sep 10, 2014, at 12:41 PM, Boris Zbarsky wrote:
On 9/10/14, 3:20 PM, Allen Wirfs-Brock wrote:
why wouldn't a self-hoster just continue with:
for (let next of iter} {
/* body */
}
I feel like I'm missing something here.
iter is an iterator, not an iterable. So I don't think
On 9/10/14, 4:11 PM, Allen Wirfs-Brock wrote:
In practice (because of for-of semantics) Iterators need to be Iterables
that return themselves as the associated iterator. All built-in
iterators in ES have this characteristic
Ah, I see. But that's observably different from just doing the loop
/ Seems to me like it's just a matter of wrapping the relevant bits (which
ones, though?
// whatever constitutes the loop body
//
// OK. That's fairly straightforward.
//
// You also will need a finally clause, if the loop body contains any explicit returns.
//
// It only does when
On Wed, Sep 10, 2014 at 10:33 AM, Brendan Eich bren...@mozilla.org wrote:
Matthew Robb wrote:
I don't see why they have to? Traceur should be used as a build time tool
that ultimately runs in legacy mode. Only REAL modern ES6 module
implementations would run in this other world. Basically
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Boris
Zbarsky
On 9/10/14, 10:45 AM, Erik Arvidsson wrote:
1. Add IteratorClose to all places in the spec where we use iterators.
And other specs (e.g. Web IDL) that use iterators, right?
Relatedly, it would be *really*
On 9/10/14, 4:57 PM, Domenic Denicola wrote:
Relatedly, it would be *really* nice to have a spec-level for-of, both for ES
and for web specs.
You mean so people don't have to write things like
http://heycam.github.io/webidl/#add-map-elements-from-iterable by hand?
Yeah, it would.
(Not
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
On 9/10/14, 4:57 PM, Domenic Denicola wrote:
Relatedly, it would be *really* nice to have a spec-level for-of, both for
ES and for web specs.
You mean so people don't have to write things like
On 9/10/14, 5:12 PM, Domenic Denicola wrote:
For https://github.com/heycam/webidl/pull/18, I think it would be ideal to use
exact for-of if possible, perhaps after an initial discrimination, instead of
manually doing all those things to the iterable.
Again, I basically copied Array.from,
On Wed, Sep 10, 2014 at 11:28 AM, Guy Bedford guybedf...@gmail.com wrote:
But within that you would also need a distinction of CommonJS or global as
well?
One way might be to set up configuration to know which module names are of
which format:
```
System.metadata['test/*'] = {
format:
Michal - Why have it only throw in strict mode? Tuples would be a new
construct, so no breaking of the web if it throws in all contexts.
Jasper - It's not necessarily a given, but the immutability of tuples
offers some guarantees that are easier to optimize against. E.g., no need
to pre-allocate
I think the point I was trying to originally make was that if you want to
take full advantage of the loader, you don't want to, in the long run,
treat CommonJS as a global script, running the NodeJS loader and System
loader both side-by-side, you want to be able to unify on a single loader.
When
On Sep 10, 2014, at 2:12 PM, Domenic Denicola wrote:
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
On 9/10/14, 4:57 PM, Domenic Denicola wrote:
Relatedly, it would be *really* nice to have a spec-level for-of, both for
ES and for web specs.
You mean so people don't have to write
On Wed, Sep 10, 2014 at 9:21 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 10, 2014, at 8:44 AM, Matthew Robb wrote:
Personally I have felt this way for a long time as well. I think `.esm` is
somewhat confusing since most js developers don't really think about it as
EcmaScript.
with all due respect Rick, and you know we've been talking about this
already, your forEach = example assumes you have created a subclassed
Array ... which trust me, it's the least common case you gonna have in the
real world 'cause basically impossible before ES6.
Everybody else that used to
So... Your saying bring environmental scope to the script file... As
having it's own context execution... Like each script tag is its own iframe or
DOM environment, while in the same html page?
E-S4L
N-S4L
On Sep 10, 2014, at 2:24 PM, Matthew Robb matthewwr...@gmail.com wrote:
I don't
On Wed, Sep 10, 2014 at 4:14 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
with all due respect Rick, and you know we've been talking about this
already, your forEach = example assumes you have created a subclassed
Array ... which trust me, it's the least common case you gonna have
assumes you have created a subclassed Array ... which trust me, it's the least common case you gonna have in the real world I've been subclassing arrays in at least two separate projects, and it is very much possible via prototype injection. You (almost) can't intercept direct arr[x] calls, but
Alex Kocharin wrote:
Everybody else that used to pass a different context to do something
more meaningful
Does anyone really do that? Except for fine-tuning performance? As far
as I remember, people either use closures or .bind() stuff.
Yup.
Andrea, if you want - (which you do) can you
On 9/10/14, 5:48 PM, Allen Wirfs-Brock wrote:
Why not just us ES as the specification language for most things in the WebIDL world? Or
if not full ES, a simplified form Spec-ES.
There are a few issues with using ES for specifying Web IDL. It's
possible that these can be overcome, of
For what it's worth, node already deals with 'modules' versus 'plain
scripts'. The latter typically start with `#!` and are found in a `bin`
subdirectory. In case of ambiguity you can add `/* jshint ... */`
directives as necessary to select the appropriate language mode. I don't
see this as a
Wrt to the proposed `default.js` convention: node doesn't *need* to
specify a main entry point in the `package.json`. It could have chosen an
arbitrary convention.
Clearly, and it already did: index.js. My (perhaps imperfect)
understanding of history is that support for the main
On Fri, Aug 29, 2014 at 2:23 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 29 Aug 2014, David Herman wrote:
It's still not completely clear to me what your use cases are, so I'm
not sure exactly how much user-visible API you need.
My goal is to avoid browsers having to implement two
On 9 September 2014 16:51, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Well, just for fun
const N = \n; //maybe we could find evocative unicode name.
var a = `This is a template string. ${
N}Even though each line is indented to keep the ${
100 matches
Mail list logo
