On Fri, Jun 20, 2014 at 2:03 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> I am trying to stay outside this discussion as much as I can but there is
> a specific sentence that I'd like to understand:
>
>
> On Fri, Jun 20, 2014 at 8:39 AM, John Barton
On Fri, Jun 20, 2014 at 6:42 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> > Can you develop these particular accusations?
> > Why would TC39 have priorities that don't align with the needs of
> developers? especially on modules which are clearly one of the most awaited
> feature as
On Thu, Jun 19, 2014 at 10:48 AM, Axel Rauschmayer wrote:
> On Jun 19, 2014, at 16:17 , John Barton wrote:
>
> Sorry to be dense, but I would appreciate more elaboration of this
> sentence:
>
>
> On Thu, Jun 19, 2014 at 3:40 AM, Axel Rauschmayer
> wrote:
>
>>
Sorry to be dense, but I would appreciate more elaboration of this sentence:
On Thu, Jun 19, 2014 at 3:40 AM, Axel Rauschmayer wrote:
> This is a key sentence in David’s proposal: “ES6 favors the single/default
> export style,
>
What is the "single/default" export style? If I understand this
If you want both to have
> an ideal experience you want bundles of modules and delta compression of
> your changes. Unfortunately, there isn't a good delta compression solution
> yet but I have hopes that SDCH might be made more general and standard.
>
>
> On Mon, Jun 16, 2014 at 4:
On Mon, Jun 16, 2014 at 4:49 PM, caridy wrote:
> > I thought SPDY was, to quote wikipedia, about: "reducing web page load
>> latency and improving web security"
>> > How does SPDY help when the issue is lots of small requests ping
>> ponging back and forth between client and server?
>>
>> SPDY mu
On Mon, Jun 16, 2014 at 4:04 PM, caridy wrote:
> > I thought SPDY was, to quote wikipedia, about: "reducing web page load
> latency and improving web security"
> > How does SPDY help when the issue is lots of small requests ping ponging
> back and forth between client and server?
>
> SPDY multipl
On Mon, Jun 16, 2014 at 3:42 PM, caridy wrote:
> On Jun 16, 2014, at 5:41 PM, Frankie Bagnardi
> wrote:
>
> > The other big concern here is that in production, very few people are
> going to be loading every JavaScript file asynchronously. If there's
> magic, there needs to be a reasonable way
On Sun, Jun 15, 2014 at 8:32 PM, Axel Rauschmayer wrote:
> I apologize for this email, but I still don’t understand the current
> module design.
> ...
> **Single-export modules.** Still missing is support for single-export
> modules, which could be added as follows (the keyword `default` instead
One unusual but interesting metric: try to find blog posts explaining
module m from 'mymodule';
vs posts explaining import. At least my attempts failed.
Basically authors who thought ES6 modules are worth explaining did not
think 'module' was worth explaining.
jjb
On Thu, Jun 12, 2014 at 2
On Thu, Jun 12, 2014 at 7:43 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> I like , simply as a better . Whether it's worth the
> cost is largely a matter of finding out what the cost is, from
> implementers. I don't recall reading any opinions from them on the matter.
>
>
> Hixi
I urge TC39 to assess the cost/benefit of carefully. It brings in
a lot of issues orthogonal to JS. is already a mess and HTML
Imports are barely a thing. Web developers need a solution to the bundling
problem for ES modules with much, much higher priority than .
On Thu, Jun 12, 2014 at
The Traceur project would be interested in your issues and in a discussion
on how to improve. Improvements are easy to try.
jjb
On Wed, Jun 11, 2014 at 1:25 PM, Matthew Robb
wrote:
>
> I have been working extensively with modules in a project that will be
> going live this year. I am using tr
On Mon, Jun 9, 2014 at 9:40 AM, Caridy Patino wrote:
> another issue with `this` being `global` (as it is today by the specs) is
> the way top level modules will be defined in a page, assuming we will have
> `type="module"` for scripts (which is probably were we want to be), what
> will be the di
On Mon, Jun 9, 2014 at 9:17 AM, Mark S. Miller wrote:
> On Mon, Jun 9, 2014 at 9:08 AM, John Barton
> wrote:
> [...]
>
> but ES6 is a class-based language: based on our experience the majority
>> of exports going forward will be classes.
>>
>
> Hi John, that
Just another related issue: in Traceur code we use 'this' in modules to
mean 'global', because in modules we have no other way to say 'global' in
code designed to work in browsers and node.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://m
On Mon, Jun 9, 2014 at 7:51 AM, Axel Rauschmayer wrote:
> I’m assuming that people will default-export objects (for
> Underscore.js-like libraries). I’d call those pseudo-modules, because one
> would be partially working around the module system (no load-time errors!).
>
Then aren't you arguing
On Mon, Jun 9, 2014 at 6:54 AM, Axel Rauschmayer wrote:
> On the other hand, we’ll have many pseudo-modules, which is also a barrier
> against making progress later on.
>
Sorry, I don't understand what a pseudo-module is. Are you saying that the
core import/export system is not correct and that
If the 'module' form is left out, it can be added later. If the 'module'
form is left in, it can never be removed.
jjb
On Mon, Jun 9, 2014 at 6:39 AM, Axel Rauschmayer wrote:
> Isn't the problem, though, that default-exporting an object prevents
> static checking? It feels like an abuse of this
al".
On Thu, Jun 5, 2014 at 7:34 AM, Andreas Rossberg
wrote:
> On 5 June 2014 16:08, John Barton wrote:
> > On Thu, Jun 5, 2014 at 2:06 AM, Andreas Rossberg
> > wrote:
> >>
> >> On 4 June 2014 23:46, John Lenz wrote:
> >> > I don't person
On Thu, Jun 5, 2014 at 2:06 AM, Andreas Rossberg
wrote:
> On 4 June 2014 23:46, John Lenz wrote:
> > I don't personally want to write sloppy mode code, but there are places
> you
> > need it (using eval to introduce new symbols into global scope).
>
> You don't necessarily need sloppy mode for t
On Thu, May 29, 2014 at 4:05 PM, Ian Hickson wrote:
> On Thu, 29 May 2014, John Barton wrote:
> > On Thu, May 29, 2014 at 2:31 PM, Ian Hickson wrote:
> > > On Thu, 29 May 2014, Juan Ignacio Dopazo wrote:
> > > > >
> > > > > - some people
On Thu, May 29, 2014 at 2:31 PM, Ian Hickson wrote:
> On Thu, 29 May 2014, Juan Ignacio Dopazo wrote:
> > >
> > > - some people want to predeclare a bunch of scripts and their
> > > dependencies, without actually downloading any of them ahead of time,
> > > and then later, when they're needed
On Thu, May 29, 2014 at 7:45 AM, Anne van Kesteren wrote:
> On Thu, May 29, 2014 at 4:40 PM, John Barton
> wrote:
> > My intuition is that any such plan would be vigorously opposed by the JS
> > community. Or perhaps vigorously ignored: browsers are falling behind
> > cu
My intuition is that any such plan would be vigorously opposed by the JS
community. Or perhaps vigorously ignored: browsers are falling behind
current technology and are no longer in a position to dictate what JS means.
On Wed, May 28, 2014 at 9:06 PM, Kevin Smith wrote:
>
>> Ok. I'm not really
On Wed, May 28, 2014 at 4:20 PM, Ian Hickson wrote:
> On Wed, 28 May 2014, John Barton wrote:
> > >
> > > Is the list that Juan described (see below) the list you had in mind?
> >
> > Yes.
>
> Cool, thanks. (It would be great if this list could be mor
On Wed, May 28, 2014 at 3:26 PM, Ian Hickson wrote:
> On Tue, 27 May 2014, John Barton wrote:
> > On Tue, May 27, 2014 at 4:51 PM, Ian Hickson wrote:
> > > On Tue, 27 May 2014, John Barton wrote:
> > > > >
> > > > > Is System somet
On Tue, May 27, 2014 at 4:51 PM, Ian Hickson wrote:
> On Tue, 27 May 2014, John Barton wrote:
> > >
> > > Is System something that we are expecting some non-ES spec, e.g. Fetch
> > > or HTML, to define?
> >
> > TC39 members have more than once explaine
On Tue, May 27, 2014 at 3:57 PM, Ian Hickson wrote:
>
> On Tue, 27 May 2014, John Barton wrote:
> >
> > I think the Loader nicely isolates these particular functions: I don't
> > see any urgency in standardizing them. However the delegation of the
> > speci
On Tue, May 27, 2014 at 3:04 PM, Ian Hickson wrote:
>
>
> On Tue, 27 May 2014, John Barton wrote:
> > On Fri, May 23, 2014 at 5:04 PM, Ian Hickson wrote
>
...
>
> > > and how would we hook all the specs together to use it?
> >
> > Define a "System
an ES6 Loader in an HTML Import, the registry will be automatically
shared).
On Tue, May 27, 2014 at 8:28 AM, Matthew Robb wrote:
> On Tue, May 27, 2014 at 8:09 AM, John Barton wrote:
>
>>
>>
>>
>> On Fri, May 23, 2014 at 5:04 PM, Ian Hickson wrote
>>
>&g
On Fri, May 23, 2014 at 5:04 PM, Ian Hickson wrote
>
>
> What/where would be the best place to define such a system,
Github.
> and how would
> we hook all the specs together to use it?
Define a "System" object for ES6 that implements the ES6 Loader API and
extends it to dynamically load CSS
r o = {};
> Object.defineProperty(o, '__proto__', {
> get: function () {
> return String.prototype;
> }
> });
>
> o.__proto__ === String.prototype;
> Object.getPrototypeOf(o); // Object.prototype
> ```
>
> Best Regards
>
>
>
> On Mon, Ma
Thanks, Boris, this explanation solves the puzzle for me.
On Mon, May 5, 2014 at 1:32 PM, Boris Zbarsky wrote:
> On 5/5/14, 4:21 PM, John Barton wrote:
>
>> Let me rephrase my question: why is the Proxy get even called in this
>> case?
>>
>
> Because the way _
On Mon, May 5, 2014 at 11:44 AM, Allen Wirfs-Brock wrote:
>
> On May 5, 2014, at 10:40 AM, John Barton wrote:
>
> I'm hoping someone can explain this result which surprises me.
>
> If I create an object with a Proxy-ed prototype, the resulting object does
>
I'm hoping someone can explain this result which surprises me.
If I create an object with a Proxy-ed prototype, the resulting object does
not obey .__proto__ equal Object.getPrototypeOf().
For example:
var aPrototype = {foo: 'foo'};
var handler = {
get: function(target, name, receiver) {
On Sun, May 4, 2014 at 3:00 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> +1 and as generic global utility it would be also nice to make it
> compatible with all strings.
>
A language with modules does not need nor should it rely on stuff more
favorite features onto global. We ne
On Mon, Apr 7, 2014 at 10:51 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> ..
>
> It feels like everyone uses `__proto__` on daily basis while ES6 promotes
> classes ... so either `__proto__` is not a real world use case, or `class`
> landed for no reason, IMO.
>
You are correct,
The context for my question was Tom van Cutsem's excellent Proxy shim,
https://github.com/tvcutsem/harmony-reflect, which uses __proto__
assignment to shim Object.setPrototypeOf. In developing Proxy code,
objects and not classes are relevant. Directly manipulating the __proto__
is vastly superior
I was surprised to discover that in chrome at least this is valid:
var obj = {};
obj.__proto__ = undefined;
but this throws
Object.setPrototypeOf(obj, undefined);
Is it intended?
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.
On Tue, Apr 1, 2014 at 11:08 AM, Jacob Gable wrote:
> ...
>
> Finally, my real question is, can I achieve a "shimming" system like
> requirejs (http://requirejs.org/docs/api.html#config-shim) has through
> the creation of a custom Loader? It seems like the Instantiate method
> could be overridde
ot; but might be limiting for "soureMappingUrl".
>
>
>
> On Sun, Mar 30, 2014 at 6:25 PM, John Barton wrote:
>
>> Hi Mark. I implemented the first sourceURL support, for Firebug back in
>> the day. It's a kludge we worked out because there was no altern
Hi Mark. I implemented the first sourceURL support, for Firebug back in
the day. It's a kludge we worked out because there was no alternative. It
forces debuggers seek the ends of buffers even if they are millions of
bytes and even if the the name does not turn out to be the one the dev was
intere
Notice that the eval stack trace is not very useful in the common case that
the buffer is more complex than a single line and the eval is called more
than once. For eval, new Function(), document.write(),
document.appendChild(