On 11/1/2013 8:54 PM, Allen Wirfs-Brock wrote:
This just reminds me how cold I still am on the fact that you can't easily
one-off Proxy anything that's not a plain Object, Array, or Function because of
the lack of an invoke trap and every other type of built-in has private
state... but I suppo
On Oct 31, 2013, at 8:06 AM, Erik Arvidsson wrote:
> Make sense but I'm not sure it is needed/desired.
I agree, actually, despite being the one who put it in there in the first
place. I originally intended it as a convenience e.g. for quick scripts. But by
itself it's simply too brittle to wor
On Nov 1, 2013, at 7:27 PM, Brandon Benvie wrote:
> On 11/1/2013 7:13 PM, Allen Wirfs-Brock wrote:
>> Or we could simply not special case Proxy exotic objects and then Proxies
>> would be handled like any other object, the value of the objects
>> @@toStringTag property would be accessed and use
On 11/1/2013 7:13 PM, Allen Wirfs-Brock wrote:
Or we could simply not special case Proxy exotic objects and then Proxies would
be handled like any other object, the value of the objects @@toStringTag
property would be accessed and used to compose the toString result.
Which would result in thi
On Nov 1, 2013, at 6:05 PM, David Bruant wrote:
> Le 02/11/2013 01:08, Brandon Benvie a écrit :
>> On 11/1/2013 4:59 PM, Brandon Benvie wrote:
>>> On 11/1/2013 4:31 PM, Brandon Benvie wrote:
In the spec for Object.prototype.toString:
'If tag is any of "Arguments", "Array", "Boolea
On Nov 1, 2013, at 6:19 PM, David Herman wrote:
> On Nov 1, 2013, at 7:44 AM, Jason Orendorff wrote:
>
>> Now... good use cases could be a sufficient counterargument to all
>> this. Maybe we should add `import * from` in 2014. I just want to make
>> it totally clear why it's designed this way f
On Nov 1, 2013, at 7:44 AM, Jason Orendorff wrote:
> Now... good use cases could be a sufficient counterargument to all
> this. Maybe we should add `import * from` in 2014. I just want to make
> it totally clear why it's designed this way for ES6. `import * from`
> poses significant problems, bot
On Oct 31, 2013, at 7:10 AM, Erik Arvidsson wrote:
> I see that Jason added a Loader.prototype.define to his reference
> implementation.
> https://people.mozilla.org/~jorendorff/js-loaders/Loader.html#section-177.
> This is great. It is a much needed capability to allow bundling modules into
Le 02/11/2013 01:08, Brandon Benvie a écrit :
On 11/1/2013 4:59 PM, Brandon Benvie wrote:
On 11/1/2013 4:31 PM, Brandon Benvie wrote:
In the spec for Object.prototype.toString:
'If tag is any of "Arguments", "Array", "Boolean", "Date", "Error",
"Function", "Number", "RegExp", or "String" and
On 11/1/2013 4:59 PM, Brandon Benvie wrote:
On 11/1/2013 4:31 PM, Brandon Benvie wrote:
In the spec for Object.prototype.toString:
'If tag is any of "Arguments", "Array", "Boolean", "Date", "Error",
"Function", "Number", "RegExp", or "String" and SameValue(tag,
builtinTag) is false, then let
On 11/1/2013 4:31 PM, Brandon Benvie wrote:
In the spec for Object.prototype.toString:
'If tag is any of "Arguments", "Array", "Boolean", "Date", "Error",
"Function", "Number", "RegExp", or "String" and SameValue(tag,
builtinTag) is false, then let tag be the string value "~"
concatenated wit
I just read
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.prototype.tostring
and
agree that it continues to preserve the brand checks that were reliable in
ES5.
Cool! Thanks!
On Fri, Nov 1, 2013 at 4:31 PM, Brandon Benvie wrote:
> On 11/1/2013 4:29 PM, Mark S. Miller wrote:
On 11/1/2013 4:29 PM, Mark S. Miller wrote:
Hi Allen, perhaps I misunderstood. But I thought that as of ES6,
O.p.toString can't be used for reliable brand checking of anything,
including legacy ES<=5 built-ins. Not so? How would I do such a check
of a legacy built-in in ES6?
In the spec for O
On Fri, Nov 1, 2013 at 4:03 PM, Allen Wirfs-Brock wrote:
>
> On Nov 1, 2013, at 12:16 PM, Andrea Giammarchi wrote:
>
> > Allen I think we all agree duck typing is more flexible, powerful, easy,
> etc etc ... but since you mentioned, how would do distinguish between a
> `Map` and a `WeakMap` withou
On Fri, Nov 1, 2013 at 2:19 PM, Jeff Morrison wrote:
> (I'm operating on the assumption that the Module constructor is still part
> of the spec):
>
> ```
> System.define({
> A: {
> deps: ['B','C'],
> factory: function(B, C) {
> var stuff = B.doSomething();
> return new Module
On Nov 1, 2013, at 1:11 PM, Mark S. Miller wrote:
> For the ES6 builtin types, I have no idea.
>
Most branded ES6 built-ins have non-destructive brand-checking methods that
call be used to perform brand checks.
For example,
function isMap(obj) {
try {Map.prototype.size.call(obj); retu
On Nov 1, 2013, at 12:16 PM, Andrea Giammarchi wrote:
> Allen I think we all agree duck typing is more flexible, powerful, easy, etc
> etc ... but since you mentioned, how would do distinguish between a `Map` and
> a `WeakMap` without passing through the branding check ?
>
> That's a very good
(I'm operating on the assumption that the Module constructor is still
part of the spec):
```
System.define({
A: {
deps: ['B','C'],
factory: function(B, C) {
var stuff = B.doSomething();
return new Module({stuff: stuff});
}
},
B: {
deps: ['D', 'E'],
factory:
On 11/1/2013 1:28 PM, James Burke wrote:
Perhaps you know how a mutable slot could be expressed using existing
syntax for creating Module objects? Illustrating how would clear up a
big disconnect for me.
If I'm understanding what you mean by "mutable slot", the only way it
can be expressed cur
On Fri, Nov 1, 2013 at 1:04 PM, Jeff Morrison wrote:
> No, that's why I said the function generates an instance of a Module object
> imperatively (we're already in imperative definition land with this API
> anyway).
> No need for `import` or `export`
My understanding is that there is no way to ex
http://wiki.ecmascript.org/doku.php?id=strawman:relationships
On Fri, Nov 1, 2013 at 1:11 PM, Mark S. Miller wrote:
> For the ES6 builtin types, I have no idea.
>
> For abstractions you define yourself, your abstraction can brand its
> objects using an encapsulated WeakSet or WeakMap. This will
For the ES6 builtin types, I have no idea.
For abstractions you define yourself, your abstraction can brand its
objects using an encapsulated WeakSet or WeakMap. This will work, but with
two problems:
* Awkward syntax until more directly supported by ES7 relationships.
* Sucky performance until
On 11/1/13, 11:32 AM, James Burke wrote:
On Thu, Oct 31, 2013 at 8:32 PM, Jeff Morrison wrote:
Throwing this out there while I stew on the pros/cons of it (so others can
as well):
I wonder how terrible it would be to have this API define module bodies in
terms of a passed function that, say, a
Thanks Mark,
so how is anyone supposed to be sure about or check a Brand in ES6 then?
On Fri, Nov 1, 2013 at 1:00 PM, Mark S. Miller wrote:
>
>
>
> On Fri, Nov 1, 2013 at 12:16 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> Allen I think we all agree duck typing is more
On Fri, Nov 1, 2013 at 12:16 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> Allen I think we all agree duck typing is more flexible, powerful, easy,
> etc etc ... but since you mentioned, how would do distinguish between a
> `Map` and a `WeakMap` without passing through the branding
Allen I think we all agree duck typing is more flexible, powerful, easy,
etc etc ... but since you mentioned, how would do distinguish between a
`Map` and a `WeakMap` without passing through the branding check ?
That's a very good example indeed, `'has' in obj` or `'set' in obj` does
not grant you
If we limit `module 'm' { ... }` to Script then we still keep the flat
module hierarchy.
On Nov 1, 2013 2:32 PM, "James Burke" wrote:
> On Thu, Oct 31, 2013 at 8:32 PM, Jeff Morrison
> wrote:
> > Throwing this out there while I stew on the pros/cons of it (so others
> can
> > as well):
> > I won
On Nov 1, 2013, at 10:40 AM, Anne van Kesteren wrote:
> On Fri, Nov 1, 2013 at 12:50 AM, Allen Wirfs-Brock
> wrote:
>> [isSpecialString]() {return isSpecialString in this};
>
> So this is basically what we have for DOM objects right now. And what
> we're asking for is having this elevated to la
On Thu, Oct 31, 2013 at 8:32 PM, Jeff Morrison wrote:
> Throwing this out there while I stew on the pros/cons of it (so others can
> as well):
> I wonder how terrible it would be to have this API define module bodies in
> terms of a passed function that, say, accepted and/or returned a module
> ob
On Fri, Nov 1, 2013 at 12:50 AM, Allen Wirfs-Brock
wrote:
> [isSpecialString]() {return isSpecialString in this};
So this is basically what we have for DOM objects right now. And what
we're asking for is having this elevated to language-supported
construct. Be it in the form of a method or someth
I have no idea who is doing that and why but yes, in that case I would
never have used instanceof so my example is still valid as use case itself.
Cheers
On Thu, Oct 31, 2013 at 11:54 PM, Oliver Hunt wrote:
>
> On Nov 1, 2013, at 7:23 PM, Andrea Giammarchi
> wrote:
>
> also, your reviver woul
On Fri, Nov 1, 2013 at 3:55 PM, Allen Wirfs-Brock wrote:
> There is still plenty of work to do to reach the Ecma standard stage in Dec
> 2014, but from a feature perspective ES6 should be "done" within the next 3
> months.
>
Excellent news, thanks for the summary.
__
Thanks Rick,
>From my reading of that schedule we could hope to have ES6 features
like modules and classes ready for use in production code (via
something like traceur) by Q1 next year?
The June/July/Dec 2014 dates are simply dot the i's and cross the t's
milestones, standardisation bureaucracy?
On Nov 1, 2013, at 6:23 AM, Rick Waldron wrote:
>
>
> On Fri, Nov 1, 2013 at 12:02 AM, Nathan Wall wrote:
> Hey guys, I really think you're all doing an awesome job with the development
> of the future of the language, especially all the work Allen's putting into
> the drafts. I'm really dy
I suppose I am hypothesising that it might be possible to limit the
invocation to the outer scope only in some CSP mode.
// allowed:
System.define(['some-module'], ['export var q = "p";']);
// not allowed:
(function() {
System.define(['some-module'], ['export var q = "p";']);
})();
In this way
On Thu, Oct 31, 2013 at 11:06 AM, Erik Arvidsson
wrote:
> Make sense but I'm not sure it is needed/desired.
It's very useful for convenience libraries, quick refactorings, etc.
In other languages, I use it a lot.
> Where is this documented?
It's very briefly described in the wiki page, and full
On Thu, Oct 31, 2013 at 12:40 PM, Erik Arvidsson
wrote:
> On Thu, Oct 31, 2013 at 1:22 PM, Jason Orendorff
> wrote:
>> import * from "stickers";
>> ...
>> y = r * Math.sin(a);
>> ...
>>
>> It is unclear whether `Math` refers to the global Math or to something
>> imported from
I think I must be missing something?
On Fri, Nov 1, 2013 at 6:47 AM, Guy Bedford wrote:
> Surely this can be dealt with by extending the CSP policy to allow script
> domains which are able to call System.define.
>
How is that different to extending the CSP policy to allow script domains
to call
On Fri, Nov 1, 2013 at 12:02 AM, Nathan Wall wrote:
> Hey guys, I really think you're all doing an awesome job with the
> development of the future of the language, especially all the work Allen's
> putting into the drafts. I'm really dying to start using some of these
> features.
>
> Last I hea
> Finalized spec or finalized implementations?
>
> A lot of things are already being implemented (with varying levels of
> conformance, of course) in latest versions of engines (from browsers to
> node) — http://kangax.github.io/es5-compat-table/es6/
>
> --
> kangax
Yes, thanks, I'm aware
Surely this can be dealt with by extending the CSP policy to allow script
domains which are able to call System.define. Surely it is an equivalent
permission to being able to load script from the domain anyway, when it is
restricted to running in the outer scope only?
On 31 October 2013 16:10, Er
Finalized spec or finalized implementations?
A lot of things are already being implemented (with varying levels of
conformance, of course) in latest versions of engines (from browsers to
node) — http://kangax.github.io/es5-compat-table/es6/
--
kangax
On Fri, Nov 1, 2013 at 5:02 AM, Nathan Wall
42 matches
Mail list logo
