Re: Cross-global instanceof

[Oliver Hunt]

On Nov 1, 2013, at 7:23 PM, Andrea Giammarchi  
wrote:

> also, your reviver would receive objects from the realm I am checking with 
> that code ... so your reviver will receive object from the **expected** realm 
> ... just to clarify, for future readers.
> 

I don’t understand what you’re saying here

if your reviver is in realm A, and says

function reviver(foo) {
…
  if (foo instance of Array) alert(“Array!”)
...
}

And realm B says

JSON.parse(…, realm A.reviver)

You will never get to the alert.

As far as use cases, i recall multiple websites using invisible iframes as 
“modules” where multiple realms would use a shared group of functions from a 
single realm

—Oliver

> Still all ears listening to that case I've never, honestly, considered!
> 
> Thanks
> 
> 
> On Thu, Oct 31, 2013 at 11:07 PM, Andrea Giammarchi 
>  wrote:
> Sure, so Allen asked me a real case to show, and I've done it. Now you please 
> show me a real case when you pass a revival function to `JSON.parse` that is 
> from another realm, explaining why, as I've done for mine, thanks.
> 
> Best Regards
> 
> 
> On Thu, Oct 31, 2013 at 7:41 PM, Oliver Hunt  wrote:
> 
> On Nov 1, 2013, at 2:46 PM, Andrea Giammarchi  
> wrote:
> 
> > Allen, in which place on current known universe, when you parse a 
> > JSON.string, your reviver function receives objects from another realm, 
> > exactly?
> Please try to keep the discourse polite.
> 
> That said this is fairly trivial
> 
> 
> function reviver(…) { … }
> 
> 
> 
> JSON.parse(… .reviver …)
> 
> 
> now the realm of the objects created by the JSON object differ from the realm 
> that the reviver function is working in.
> 
> —Oliver
> 
> 
> 
> 
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Cross-global instanceof

[Andrea Giammarchi]

also, your reviver would receive objects from the realm I am checking with
that code ... so your reviver will receive object from the **expected**
realm ... just to clarify, for future readers.

Still all ears listening to that case I've never, honestly, considered!

Thanks


On Thu, Oct 31, 2013 at 11:07 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> Sure, so Allen asked me a real case to show, and I've done it. Now you
> please show me a real case when you pass a revival function to `JSON.parse`
> that is from another realm, explaining why, as I've done for mine, thanks.
>
> Best Regards
>
>
> On Thu, Oct 31, 2013 at 7:41 PM, Oliver Hunt  wrote:
>
>>
>> On Nov 1, 2013, at 2:46 PM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>> > Allen, in which place on current known universe, when you parse a
>> JSON.string, your reviver function receives objects from another realm,
>> exactly?
>> Please try to keep the discourse polite.
>>
>> That said this is fairly trivial
>>
>> 
>> function reviver(…) { … }
>> 
>>
>> 
>> JSON.parse(… .reviver …)
>> 
>>
>> now the realm of the objects created by the JSON object differ from the
>> realm that the reviver function is working in.
>>
>> —Oliver
>>
>>
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Cross-global instanceof

[Andrea Giammarchi]

Sure, so Allen asked me a real case to show, and I've done it. Now you
please show me a real case when you pass a revival function to `JSON.parse`
that is from another realm, explaining why, as I've done for mine, thanks.

Best Regards


On Thu, Oct 31, 2013 at 7:41 PM, Oliver Hunt  wrote:

>
> On Nov 1, 2013, at 2:46 PM, Andrea Giammarchi 
> wrote:
>
> > Allen, in which place on current known universe, when you parse a
> JSON.string, your reviver function receives objects from another realm,
> exactly?
> Please try to keep the discourse polite.
>
> That said this is fairly trivial
>
> 
> function reviver(…) { … }
> 
>
> 
> JSON.parse(… .reviver …)
> 
>
> now the realm of the objects created by the JSON object differ from the
> realm that the reviver function is working in.
>
> —Oliver
>
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

ES6 Timeline

[Nathan Wall]

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 heard (probably over a year ago), the plan was to have ES6 out by the 
end of this year...  It still looks like there's a good bit of work to be done 
for things to be finalized.  Are there any updates on when we can hope to have 
a finalized ES6?

Nathan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Modules loader define method

[Jeff Morrison]

This is excellent, but I had been worried about a string/eval-based 
define() API as well.


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 object?


-Jeff

On 10/31/13, 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 a single file.


It allows you to do something like

System.define(['url-a', urlB], ['export var a = "a";', 
moduleBodyForUrlB]);


However, this is just another form of eval and will therefore not be 
available in CSP. Can we come up with something that works in CSP 
environments? How about?


module 'url-a' {
  export var a = "a";
}

=P

--
erik


___
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: Cross-global instanceof

[Oliver Hunt]

On Nov 1, 2013, at 2:46 PM, Andrea Giammarchi  
wrote:

> Allen, in which place on current known universe, when you parse a 
> JSON.string, your reviver function receives objects from another realm, 
> exactly?
Please try to keep the discourse polite.

That said this is fairly trivial


function reviver(…) { … }



JSON.parse(… .reviver …)


now the realm of the objects created by the JSON object differ from the realm 
that the reviver function is working in.

—Oliver



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Cross-global instanceof

[Andrea Giammarchi]

Allen, in which place on current known universe, when you parse a
JSON.string, your reviver function receives objects from another realm,
exactly?

That logic is bypassing and full-satisfying JSON.parse revival expectations
returning object later on checked as instanceof String in order to
differentiate and revive them differently and the same is done for Object,
where `typeof` would create a disaster in that tested logic with just a
`null` value plus CircularJSON is fully compatible with ES3 and Mr D.
Crockford JSON polyfill too so   since we'd like to have shimmable code
and Symbols are a no-go, do you still think instanceof is not needed at all?

'cause just this `null instanceof Object` is a good reason to use it when
objects are expected in a revival loop, imho.

Thanks, regardless, for spending some time on it.

Cheers


On Thu, Oct 31, 2013 at 5:50 PM, Allen Wirfs-Brock wrote:

>
> On Oct 31, 2013, at 2:56 PM, Andrea Giammarchi wrote:
>
> Sorry, secure was actually "reliable", as being secure about the type, not
> about security itself.
>
> A case where I do use instanceof is, example, with new String to easily
> decide later on what to do with such object that should not be treated as
> such.
>
> The script does resolve circular dependencies backward and forward out of
> JSON.stringiy and JSON.parse that do create objects from the current realm.
>
> Nothing else than `instanceof` is as usable/useful in current ESX spec for
> same purpose in terms of performance and reliability.
>
>
> https://github.com/WebReflection/circular-json/blob/master/src/circular-json.js#L108
>
> Just one case, still `instanceof` is used a lot and usually for good
> reasons, ...
>
>
> Well I promised I'd explain how I'd eliminate use of 'instanceof' so here
> goes. Note that since this is in the context of talking about possible ES
> extensions I'll assume those are available.
>
> First, you're using (lines 20) String wrapper objects(with the name String
> aliased to $String)  to pass around string values that require special
> processing.  Personally, I find this a little too subtle.  In ES6 I'd do
> this way instead:
>
> const isSpecialString = Symbol.for("isSpecialString");  //registration
> proposal in
> http://esdiscuss.org/topic/comments-on-sept-meeting-notes#content-76
> class SpecialString extends String {
>constructor(str) {
>super(str.slice(1)) //move string preprocessing into constructor
>}
>[isSpecialString]() {return isSpecialString in this};  //not really
> intended to be called
> }
>
> In line 110 I'd use
> Array.isArray(current)
> instead of
> current instanceof Array
> (note that JSON processing was one of the original use cases that
> motivated Array.isArray)
>
> In line 114, instead of
>  current instanceof $String ?
> i'd use
>  isSpecialString in  current ?//note works cross-realm, if that is
> what is desired.
>
> I may be missing something WRT possible cross-realm issues, but in line
> 126 I'd replace
>current instanceof Object
> with
>typeof current ==  'object'
> but, I'm really thinking that I must be missing something that motivated
> your use of instanceof.  Is the supposed to be a Realm check?
>
> ... not because we are all bad developers (I hope ...)
>
>
> No, but possibly developers who learned (or were taught be people who
> learned) about such things in a language context where static nominal class
> tests make more sense.
>
> Allen
>
>
>
>
>
> Cheers
>
>
>
> On Thu, Oct 31, 2013 at 2:32 PM, Allen Wirfs-Brock 
> wrote:
>
>>
>> On Oct 31, 2013, at 1:58 PM, Andrea Giammarchi wrote:
>>
>> I think the question is legit and this is a weak check
>>
>> `'throw' in possibleGenerator`
>>
>> specially if you have Dictionary like objects around ...
>>
>>
>> And why would such an object be passed into a context where you expect to
>> have a generator?  That would probably be an upstream bug and cause a
>> downstream failure.  Presumably you should have tests that look for such
>> failures.
>>
>>
>> 'length' in object does not tell you much, does it?
>>
>> who is that relevant?  If you need to condition something on the
>> existence of a length property, you can.  But in most situations you don't
>> want to do such tests.  Just access the property and use it/call it.  It it
>> is the right kind of object things will work.  If it is the wrong kind, it
>> is somebody's bug.
>>
>> `Object.prototype.toString` is abused all over client/server
>> libraries/utilities since ducks sometimes might look like gooses too.
>>
>>
>> Any, quite likely, most commonly used for unnecessary nominal type tests.
>>
>> So eventually would you don't want developers to really know what they
>> are dealing with and promote weak feature detections instead? It might
>> work, but that ain't secure.
>>
>>
>> Yes, no. Good OO is about letting go of knowledge of an objects
>> implementation.  In most cases you should only be concerned about the
>> object behavior you will use and not care abo

Re: Cross-global instanceof

[Allen Wirfs-Brock]

On Oct 31, 2013, at 2:56 PM, Andrea Giammarchi wrote:

> Sorry, secure was actually "reliable", as being secure about the type, not 
> about security itself.
> 
> A case where I do use instanceof is, example, with new String to easily 
> decide later on what to do with such object that should not be treated as 
> such.
> 
> The script does resolve circular dependencies backward and forward out of 
> JSON.stringiy and JSON.parse that do create objects from the current realm.
> 
> Nothing else than `instanceof` is as usable/useful in current ESX spec for 
> same purpose in terms of performance and reliability.
> 
> https://github.com/WebReflection/circular-json/blob/master/src/circular-json.js#L108
> 
> Just one case, still `instanceof` is used a lot and usually for good reasons, 
> ...

Well I promised I'd explain how I'd eliminate use of 'instanceof' so here goes. 
Note that since this is in the context of talking about possible ES extensions 
I'll assume those are available.

First, you're using (lines 20) String wrapper objects(with the name String 
aliased to $String)  to pass around string values that require special 
processing.  Personally, I find this a little too subtle.  In ES6 I'd do this 
way instead:

const isSpecialString = Symbol.for("isSpecialString");  //registration proposal 
in http://esdiscuss.org/topic/comments-on-sept-meeting-notes#content-76 
class SpecialString extends String {
   constructor(str) {
   super(str.slice(1)) //move string preprocessing into constructor
   }
   [isSpecialString]() {return isSpecialString in this};  //not really intended 
to be called
}

In line 110 I'd use
Array.isArray(current) 
instead of 
current instanceof Array 
(note that JSON processing was one of the original use cases that motivated 
Array.isArray)

In line 114, instead of
 current instanceof $String ?
i'd use
 isSpecialString in  current ?//note works cross-realm, if that is what is 
desired. 

I may be missing something WRT possible cross-realm issues, but in line 126 I'd 
replace
   current instanceof Object
with
   typeof current ==  'object'
but, I'm really thinking that I must be missing something that motivated your 
use of instanceof.  Is the supposed to be a Realm check?

> ... not because we are all bad developers (I hope ...)

No, but possibly developers who learned (or were taught be people who learned) 
about such things in a language context where static nominal class tests make 
more sense.

Allen




> 
> Cheers
> 
> 
> 
> On Thu, Oct 31, 2013 at 2:32 PM, Allen Wirfs-Brock  
> wrote:
> 
> On Oct 31, 2013, at 1:58 PM, Andrea Giammarchi wrote:
> 
>> I think the question is legit and this is a weak check
>> 
>> `'throw' in possibleGenerator`
>> 
>> specially if you have Dictionary like objects around ...
> 
> And why would such an object be passed into a context where you expect to 
> have a generator?  That would probably be an upstream bug and cause a 
> downstream failure.  Presumably you should have tests that look for such 
> failures.
>> 
>> 'length' in object does not tell you much, does it? 
>> 
> 
> who is that relevant?  If you need to condition something on the existence of 
> a length property, you can.  But in most situations you don't want to do such 
> tests.  Just access the property and use it/call it.  It it is the right kind 
> of object things will work.  If it is the wrong kind, it is somebody's bug.  
>> `Object.prototype.toString` is abused all over client/server 
>> libraries/utilities since ducks sometimes might look like gooses too.
> 
> Any, quite likely, most commonly used for unnecessary nominal type tests.
> 
>> So eventually would you don't want developers to really know what they are 
>> dealing with and promote weak feature detections instead? It might work, but 
>> that ain't secure.
> 
> Yes, no. Good OO is about letting go of knowledge of an objects 
> implementation.  In most cases you should only be concerned about the object 
> behavior you will use and not care about who implemented it or how or whether 
> or not there are multiple interoperable implementations operating.  But you 
> should be feature testing for the behavior you depend upon.  Just invoke it.  
> It the method need isn't there you are usually going to get an exception, 
> typically sooner that latter.   Feature detection shouldn't be  used as 
> poor-man nominal type checking (where you throw if it fails).  You should 
> only use feature checking, when you have real alternative paths to take 
> depending upon the presence of the feature. 
> 
> "Secure"?  What kind of security for what purpose? Every little about JS is 
> secure.
> 
> Of course, there really are some places where you really do need to do a 
> brand check for a specific object implementation.   In those cases, the 
> implementation of the object should include brand checking in its design and 
> expose an appropriate function for doing the check.  But a general purpose 
> mechanism is an attract

Re: Cross-global instanceof

[Andrea Giammarchi]

Sorry, secure was actually "reliable", as being secure about the type, not
about security itself.

A case where I do use instanceof is, example, with new String to easily
decide later on what to do with such object that should not be treated as
such.

The script does resolve circular dependencies backward and forward out of
JSON.stringiy and JSON.parse that do create objects from the current realm.

Nothing else than `instanceof` is as usable/useful in current ESX spec for
same purpose in terms of performance and reliability.

https://github.com/WebReflection/circular-json/blob/master/src/circular-json.js#L108

Just one case, still `instanceof` is used a lot and usually for good
reasons, not because we are all bad developers (I hope ...)

Cheers



On Thu, Oct 31, 2013 at 2:32 PM, Allen Wirfs-Brock wrote:

>
> On Oct 31, 2013, at 1:58 PM, Andrea Giammarchi wrote:
>
> I think the question is legit and this is a weak check
>
> `'throw' in possibleGenerator`
>
> specially if you have Dictionary like objects around ...
>
>
> And why would such an object be passed into a context where you expect to
> have a generator?  That would probably be an upstream bug and cause a
> downstream failure.  Presumably you should have tests that look for such
> failures.
>
>
> 'length' in object does not tell you much, does it?
>
> who is that relevant?  If you need to condition something on the existence
> of a length property, you can.  But in most situations you don't want to do
> such tests.  Just access the property and use it/call it.  It it is the
> right kind of object things will work.  If it is the wrong kind, it is
> somebody's bug.
>
> `Object.prototype.toString` is abused all over client/server
> libraries/utilities since ducks sometimes might look like gooses too.
>
>
> Any, quite likely, most commonly used for unnecessary nominal type tests.
>
> So eventually would you don't want developers to really know what they are
> dealing with and promote weak feature detections instead? It might work,
> but that ain't secure.
>
>
> Yes, no. Good OO is about letting go of knowledge of an objects
> implementation.  In most cases you should only be concerned about the
> object behavior you will use and not care about who implemented it or how
> or whether or not there are multiple interoperable implementations
> operating.  But you should be feature testing for the behavior you depend
> upon.  Just invoke it.  It the method need isn't there you are usually
> going to get an exception, typically sooner that latter.   Feature
> detection shouldn't be  used as poor-man nominal type checking (where you
> throw if it fails).  You should only use feature checking, when you have
> real alternative paths to take depending upon the presence of the feature.
>
> "Secure"?  What kind of security for what purpose? Every little about JS
> is secure.
>
> Of course, there really are some places where you really do need to do a
> brand check for a specific object implementation.   In those cases, the
> implementation of the object should include brand checking in its design
> and expose an appropriate function for doing the check.  But a general
> purpose mechanism is an attractive nuisance, and probably doesn't actually
> do the check you need for your specific use case.
>
>
> I still prefer `instanceof` for better performance since I don't usually
> work with different realm but I also would like to have an
> `Object.is(SomeClass, object);` facility instead of the boring, slow, and
> inappropriate `{}.toString.call(obj)` check.
>
>
> Show me real use cases and I'll try to explain with the check isn't needed.
>
> Allen
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Cross-global instanceof

[Allen Wirfs-Brock]

On Oct 31, 2013, at 1:58 PM, Andrea Giammarchi wrote:

> I think the question is legit and this is a weak check
> 
> `'throw' in possibleGenerator`
> 
> specially if you have Dictionary like objects around ...

And why would such an object be passed into a context where you expect to have 
a generator?  That would probably be an upstream bug and cause a downstream 
failure.  Presumably you should have tests that look for such failures.
> 
> 'length' in object does not tell you much, does it? 
> 
who is that relevant?  If you need to condition something on the existence of a 
length property, you can.  But in most situations you don't want to do such 
tests.  Just access the property and use it/call it.  It it is the right kind 
of object things will work.  If it is the wrong kind, it is somebody's bug.  
> `Object.prototype.toString` is abused all over client/server 
> libraries/utilities since ducks sometimes might look like gooses too.

Any, quite likely, most commonly used for unnecessary nominal type tests.

> So eventually would you don't want developers to really know what they are 
> dealing with and promote weak feature detections instead? It might work, but 
> that ain't secure.

Yes, no. Good OO is about letting go of knowledge of an objects implementation. 
 In most cases you should only be concerned about the object behavior you will 
use and not care about who implemented it or how or whether or not there are 
multiple interoperable implementations operating.  But you should be feature 
testing for the behavior you depend upon.  Just invoke it.  It the method need 
isn't there you are usually going to get an exception, typically sooner that 
latter.   Feature detection shouldn't be  used as poor-man nominal type 
checking (where you throw if it fails).  You should only use feature checking, 
when you have real alternative paths to take depending upon the presence of the 
feature. 

"Secure"?  What kind of security for what purpose? Every little about JS is 
secure.

Of course, there really are some places where you really do need to do a brand 
check for a specific object implementation.   In those cases, the 
implementation of the object should include brand checking in its design and 
expose an appropriate function for doing the check.  But a general purpose 
mechanism is an attractive nuisance, and probably doesn't actually do the check 
you need for your specific use case.

> 
> I still prefer `instanceof` for better performance since I don't usually work 
> with different realm but I also would like to have an `Object.is(SomeClass, 
> object);` facility instead of the boring, slow, and inappropriate 
> `{}.toString.call(obj)` check.

Show me real use cases and I'll try to explain with the check isn't needed.

Allen


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Cross-global instanceof

[Andrea Giammarchi]

I think the question is legit and this is a weak check

`'throw' in possibleGenerator`

specially if you have Dictionary like objects around ...

'length' in object does not tell you much, does it?

`Object.prototype.toString` is abused all over client/server
libraries/utilities since ducks sometimes might look like gooses too.

So eventually would you don't want developers to really know what they are
dealing with and promote weak feature detections instead? It might work,
but that ain't secure.

I still prefer `instanceof` for better performance since I don't usually
work with different realm but I also would like to have an
`Object.is(SomeClass, object);` facility instead of the boring, slow, and
inappropriate `{}.toString.call(obj)` check.

Just my thoughts, as usual.


On Thu, Oct 31, 2013 at 11:01 AM, Allen Wirfs-Brock
wrote:

>
> On Oct 31, 2013, at 9:43 AM, Brandon Benvie wrote:
>
> > On 10/31/2013 8:50 AM, David Bruant wrote:
> >> I'm not sure it's worth making it work for jQuery. This is trying to
> make a good use of same-origin multi-global which shouldn't exist in the
> first place. Keeping same-origin access as it is and encouraging people to
> add @sandbox even on same-origin iframes seems like a better idea.
> >>
> >> Should the addition be a nicer Object.prototype.toString.call?
> >
> > You're right, it's not instanceof. But I definitely think the argument
> can be made that there is a need for checking if something is of a certain
> class. I'm finding myself wanting things like `isGenerator` and
> `isGeneratorFunction`, for example. There's countless examples of people
> re-purposing Object.prototype.toString to serve this functionality ad hoc.
>
>
> What are the use cases for things like 'isGenerator'. When and why would
> you need to know that an object  upon which you are going to invoke the
> Iterator interface was/wasn't implemented by a generator.  If the reason is
> to know whether or not you can use the throw method (the only real
> difference between the generator object interface and the Iterator
> interface) you can test:
> 'throw' in possibleGenerator
>
> In general this sort of isFoo or obj.constructor === Foo class test is a
> bad smell in dynamic class based languages and tends to be a reflection of
> static nominal type thinking (which is fine in its own context, but JS is
> has a dynamic class model).
>
> Allen
> ___
> 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: Cross-global instanceof

[Allen Wirfs-Brock]

On Oct 31, 2013, at 9:43 AM, Brandon Benvie wrote:

> On 10/31/2013 8:50 AM, David Bruant wrote:
>> I'm not sure it's worth making it work for jQuery. This is trying to make a 
>> good use of same-origin multi-global which shouldn't exist in the first 
>> place. Keeping same-origin access as it is and encouraging people to add 
>> @sandbox even on same-origin iframes seems like a better idea.
>> 
>> Should the addition be a nicer Object.prototype.toString.call?
> 
> You're right, it's not instanceof. But I definitely think the argument can be 
> made that there is a need for checking if something is of a certain class. 
> I'm finding myself wanting things like `isGenerator` and 
> `isGeneratorFunction`, for example. There's countless examples of people 
> re-purposing Object.prototype.toString to serve this functionality ad hoc.


What are the use cases for things like 'isGenerator'. When and why would you 
need to know that an object  upon which you are going to invoke the Iterator 
interface was/wasn't implemented by a generator.  If the reason is to know 
whether or not you can use the throw method (the only real difference between 
the generator object interface and the Iterator interface) you can test:
'throw' in possibleGenerator

In general this sort of isFoo or obj.constructor === Foo class test is a bad 
smell in dynamic class based languages and tends to be a reflection of static 
nominal type thinking (which is fine in its own context, but JS is has a 
dynamic class model).

Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Modules: import *

[Erik Arvidsson]

Thanks, that makes sense.

On Thu, Oct 31, 2013 at 1:22 PM, Jason Orendorff
wrote:

> `import *` delays full knowledge of what's in the import lexical scope
>  until link time.  (That is, you can't figure out scopes by looking at
> a module in isolation. You have to wait for its dependencies.)
>
> import * from "stickers";
> ...
> y = r * Math.sin(a);
> ...
>
> It is unclear whether `Math` refers to the global Math or to something
> imported from "stickers" at least until "stickers" is loaded.
>

You have to wait for "stickers" to load to validate the imports anyway.


>
> Similarly, `export * from` delays full knowledge of what's exported
> until link time. The practical difference is that a compiler can
> benefit from having static scope information up front. Exports really
> are not needed until link time.
>

But it has a similar issue. You cannot look at a module in isolation and
know what it exports.

-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Modules: import *

[Jason Orendorff]

On Thu, Oct 31, 2013 at 9:19 AM, Erik Arvidsson
 wrote:
> I know `import * from ModuleSpecifier` was cut to make the module proposal
> simpler. However, we still have `export * from ModuleSpecifier` which has
> most of implementation complications as `import *` does.

`import *` delays full knowledge of what's in the import lexical scope
until link time.  (That is, you can't figure out scopes by looking at
a module in isolation. You have to wait for its dependencies.)

import * from "stickers";
...
y = r * Math.sin(a);
...

It is unclear whether `Math` refers to the global Math or to something
imported from "stickers" at least until "stickers" is loaded.

Similarly, `export * from` delays full knowledge of what's exported
until link time. The practical difference is that a compiler can
benefit from having static scope information up front. Exports really
are not needed until link time.

-j
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Cross-global instanceof

[Brandon Benvie]

On 10/31/2013 8:50 AM, David Bruant wrote:
I'm not sure it's worth making it work for jQuery. This is trying to 
make a good use of same-origin multi-global which shouldn't exist in 
the first place. Keeping same-origin access as it is and encouraging 
people to add @sandbox even on same-origin iframes seems like a better 
idea.


Should the addition be a nicer Object.prototype.toString.call?


You're right, it's not instanceof. But I definitely think the argument 
can be made that there is a need for checking if something is of a 
certain class. I'm finding myself wanting things like `isGenerator` and 
`isGeneratorFunction`, for example. There's countless examples of people 
re-purposing Object.prototype.toString to serve this functionality ad hoc.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Cross-global instanceof

[David Bruant]

Le 31/10/2013 16:38, Anne van Kesteren a écrit :

This keeps coming up. Last instance:
http://mxr.mozilla.org/mozilla-central/source/dom/base/ObjectWrapper.jsm#16

We have it for Array using Array.isArray().

Array.isArray is not at all equivalent to instanceof. Not even related.
Object.create(Array.prototype) instanceof Array === true

var a = [];
a.__proto__ = null;
Array.isArray(a) === true;

We need both types of checks, one for "is such object in the prototype 
chain?" and the other for "how is this object magic?" (Array, Date, 
WeakMap, File, whatev's). The source code you're linking to seems to 
want the latter.



It is unclear why the
arguments for arrays not apply to other types of objects, such as
array buffers, nodes, blobs, files, etc.

We could introduce something like

   Object.crossGlobalInstanceOf(instance, type)

which checks @@crossGlobalBrand or some such which works for built-ins
and is also usable by jQuery and the like.
I'm not sure it's worth making it work for jQuery. This is trying to 
make a good use of same-origin multi-global which shouldn't exist in the 
first place. Keeping same-origin access as it is and encouraging people 
to add @sandbox even on same-origin iframes seems like a better idea.


Should the addition be a nicer Object.prototype.toString.call?

David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 draft, Rev20 is now available

[Anne van Kesteren]

On Wed, Oct 30, 2013 at 7:52 PM, Allen Wirfs-Brock
 wrote:
> I don't understand what is special about the web APIs in this regard.  On the 
> accepting side in ES we generally allow no breaking changes.  Wherever there 
> was an existing API that accepted old-style "array likes" we now first test 
> for @@iterator and then fall back to the legacy behavior.  If there are web 
> APIs that currently accept "array-likes" and you don't do this then you are 
> really to accept a lower bar for backward compatibility than what TC39 has 
> been willing to accept.

That is not the problem.

The problem is that when designing ES it seems like you are not
considering the web ecosystem that exists around ES and how that might
need to adapt to changes in the underlying language. Or in other
words, the language does not exist in a vacuum, yet it feels like you
are designing it in that way.

This may very well be a perception and communication problem and I
think we are making progress towards addressing it, but please keep
that in mind.


-- 
http://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Cross-global instanceof

[Anne van Kesteren]

This keeps coming up. Last instance:
http://mxr.mozilla.org/mozilla-central/source/dom/base/ObjectWrapper.jsm#16

We have it for Array using Array.isArray(). It is unclear why the
arguments for arrays not apply to other types of objects, such as
array buffers, nodes, blobs, files, etc.

We could introduce something like

  Object.crossGlobalInstanceOf(instance, type)

which checks @@crossGlobalBrand or some such which works for built-ins
and is also usable by jQuery and the like.


-- 
http://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Module: export *

[Erik Arvidsson]

Make sense but I'm not sure it is needed/desired.

Where is this documented?


On Thu, Oct 31, 2013 at 10:39 AM, Sam Tobin-Hochstadt
wrote:

> This exports all of the declarations defined in the current module.  So:
>
> ```
> let x = 1;
> class foo {};
> export *;
> ```
>
> exports both `x` and `foo`.
>
> Sam
>
> On Thu, Oct 31, 2013 at 10:02 AM, Erik Arvidsson
>  wrote:
> > Both the wiki and the ES6 draft have the following as valid
> > ExportDeclaration:
> >
> >   export *
> >
> > (without a `from ModuleSpecifier`)
> >
> > What is the intended semantics for that?
> >
> > --
> > erik
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>



-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Module: export *

[Sam Tobin-Hochstadt]

This exports all of the declarations defined in the current module.  So:

```
let x = 1;
class foo {};
export *;
```

exports both `x` and `foo`.

Sam

On Thu, Oct 31, 2013 at 10:02 AM, Erik Arvidsson
 wrote:
> Both the wiki and the ES6 draft have the following as valid
> ExportDeclaration:
>
>   export *
>
> (without a `from ModuleSpecifier`)
>
> What is the intended semantics for that?
>
> --
> erik
>
> ___
> 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

Modules: import *

[Erik Arvidsson]

I know `import * from ModuleSpecifier` was cut to make the module proposal
simpler. However, we still have `export * from ModuleSpecifier` which has
most of implementation complications as `import *` does.

After using `import *` for over a year in Traceur (
https://github.com/google/traceur-compiler/commit/a8d919eda2d9d0ffd023c37b747cc979734cfaf2#diff-7b327c4c4229665f69afd29a46d100d2)
I can tell you that it would be very painful to let go of it.

-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Modules loader define method

[Erik Arvidsson]

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 a single file.

It allows you to do something like

System.define(['url-a', urlB], ['export var a = "a";', moduleBodyForUrlB]);

However, this is just another form of eval and will therefore not be
available in CSP. Can we come up with something that works in CSP
environments? How about?

module 'url-a' {
  export var a = "a";
}

=P

-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Module: export *

[Erik Arvidsson]

Both the wiki and the ES6 draft have the following as valid
ExportDeclaration:

  export *

(without a `from ModuleSpecifier`)

What is the intended semantics for that?

-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: proposal for efficient 64-bit arithmetic without value objects

[Andreas Rossberg]

On 30 October 2013 18:47, Vyacheslav Egorov  wrote:
> Some people find "global" state that this proposal introduces bad. I
> see two ways addressing this:
>
> - Returning {lo, hi} object.
>
> Pros: no global state, in combination with destructuring allows to
> write concise code, overhead can still be optimized away.
> Cons: performance of polyfill is abysmal on bad and moderately good
> VMs, requires allocation sinking pass to optimize away object
> allocation.
>
> - Make H property of the respective operation (e.g. u64mul updates its
> own property H)
>
> Pros: easy to implement, good perf on bad VMs
> Cons: still kinda global state
>
> - Math.64 can become Math.createOperator(64, ) that
> returns function with H property:
>
> var add = Math.createOperator("u64", "add");
> var dl = add(add(al, ah, bl, bh), add.H, cl, ch);
> var dh = add.H;
>
> Pros: no global state, relatively good performance on the non advanced
> VMs, can be actually extended(!) e.g. SIMD operations can be exposed
> as Math.createOperator("simd128", "add")

Instead of returning a pair, you could also do it C-style:

var ret = {}
add(al, ah, bl, bh, ret)
add(ret.lo, ret.hi, cl, ch, ret)
var dl = ret.lo, dh = ret.hi

This way, it's up to the caller to allocate a suitable return buffer
and reuse it. (For asm.js, that would probably require extending the
spec to allow a module to pre-allocate one such buffer.)

Cleaner than the other hacks, IMO, but still too ugly for an official API.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss