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

2013-10-31 Thread Andreas Rossberg
On 30 October 2013 18:47, Vyacheslav Egorov m...@mrale.ph 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.s64op can become Math.createOperator(s64, op) 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


Module: export *

2013-10-31 Thread 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


Modules loader define method

2013-10-31 Thread 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


Modules: import *

2013-10-31 Thread 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


Re: Module: export *

2013-10-31 Thread 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
erik.arvids...@gmail.com 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


Re: Module: export *

2013-10-31 Thread 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
sa...@cs.indiana.eduwrote:

 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
 erik.arvids...@gmail.com 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


Cross-global instanceof

2013-10-31 Thread 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: ES6 draft, Rev20 is now available

2013-10-31 Thread Anne van Kesteren
On Wed, Oct 30, 2013 at 7:52 PM, Allen Wirfs-Brock
al...@wirfs-brock.com 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


Re: Cross-global instanceof

2013-10-31 Thread 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: Cross-global instanceof

2013-10-31 Thread 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: Modules: import *

2013-10-31 Thread Jason Orendorff
On Thu, Oct 31, 2013 at 9:19 AM, Erik Arvidsson
erik.arvids...@gmail.com 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: Modules: import *

2013-10-31 Thread Erik Arvidsson
Thanks, that makes sense.

On Thu, Oct 31, 2013 at 1:22 PM, Jason Orendorff
jason.orendo...@gmail.comwrote:

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

2013-10-31 Thread 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: Cross-global instanceof

2013-10-31 Thread 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
al...@wirfs-brock.comwrote:


 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

2013-10-31 Thread 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

2013-10-31 Thread 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 al...@wirfs-brock.com 
 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 

Re: Cross-global instanceof

2013-10-31 Thread 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 al...@wirfs-brock.comwrote:


 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 
 al...@wirfs-brock.comwrote:


 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 

Re: Cross-global instanceof

2013-10-31 Thread Oliver Hunt

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

realm a
function reviver(…) { … }
/

realm b
JSON.parse(… realm a.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: Modules loader define method

2013-10-31 Thread 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 
https://people.mozilla.org/%7Ejorendorff/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


ES6 Timeline

2013-10-31 Thread 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