Re: Comments on Meeting Notes

[Axel Rauschmayer]

>>> * It deoptimizes, e.g. a strict-mode function must be optimized to copy
>>> actual parameter values into arguments if it could use the arguments object.
>> 
>> This one I just don't buy at all. In a strict function f, f.arguments
>> is poisoned. f's arguments would only need to be reified if f
>> statically mentions "arguments" or if f has a statically apparent use
>> of the direct eval operator. For all other cases, no arguments object
>> need be created, and therefore no copying is needed.
> 
> Right, that's what I tried to say by "could use the arguments object". 
> Nothing to do with hated f.arguments.
> 
> So every strict function that uses arguments pays a copying price on entry in 
> a naive implementation. Pushing the copies out till just before there might 
> be an aliasing store is an optimization that could be done in a more 
> sophisticated implementation, but engines don't do it currently and feel 
> little pressure to do so. Chicken and egg.


Can you explain? What is this copying price and why don’t non-strict functions 
have to pay it?

Thanks!

Axel

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

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

Creating a filled array with a given length?

[Axel Rauschmayer]

I would still love to have something like that in ES6 (loosely similar to 
String.prototype.repeat). Once you have that, you can e.g. use 
Array.prototype.map to do more things.

Two possibilities:
- Array.repeat(undefined, 3) -> [ undefined, undefined, undefined ]
- [ undefined ].repeat(3) -> [ undefined, undefined, undefined ]

The same array could be created like this, but that seems too much work for a 
relatively common operation.

'x'.repeat(3).split('').map(=> undefined)

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

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

Re: Continuum - ES6 virtual machine built in ES3

[Brandon Benvie]

Agree with all you said. And practically speaking, if I intend to support
these things in a piece of software I've written then somewhere, somehow,
there needs to be a way to tell that they work. Right now there's a lot of
things that ostensibly are supported by Continuum but for which the way to
see if it works is to attempt to run code that uses the feature and see if
it breaks or not.


On Tue, Dec 11, 2012 at 4:31 PM, David Bruant  wrote:

> Le 11/12/2012 21:46, Brandon Benvie a écrit :
>
>  http://github.com/benvie/**continuum - 
> project
>> http://benvie.github.com/**continuum - 
>> debugger
>> npm module 'continuum'
>>
>> Continuum is a virtual machine for executing ES6 code (the spec is
>> rapidly iterating so many things need updating). It's written in ES3 and
>> targets a baseline of IE8 (debugger included). With a small amount of
>> additional work it could run reliably in engines as old as IE6, but this
>> hasn't been a priority.
>>
>> Almost all ES6 features are supported to some degree: modules,
>> Proxy/Reflect, Map/Set/WeakMap, generators, 
>> destructuring/spread/rest/**default
>> params, __proto__, classes, Symbols, Typed Arrays/DataView (all features
>> work in any host engine that can run Continuum).
>>
> Awesome :-)
>
>
>  The only remaining features which are unimplemented are tail call
>> optimization (incomplete and disabled pending some changes), array
>> comprehensions, generator expressions, and new parts of the binary data API
>> (structs, etc.). Some features are incomplete and potentially buggy,
>> especially ones which are completely new and have a lot of surface area not
>> covered by test262 (proxies
>>
> I've started a test suite at 
> https://github.com/**DavidBruant/ProxyTests
> It was just for me at first, so I started with QUnit (I'll probably change
> that eventually). My end goal is to write test for the internals of
> built-in algorithms; proxies exposes them, I'd like to be sure that there
> is some minimum test suite that shows spec deviations for these (and why
> not see if proxies make engines crash when applying built-in algorithms)
> There is only one branch and I'm in the middle of a refactoring :-s
> I think you can start with this commit https://github.com/**
> DavidBruant/ProxyTests/commit/**ea53adb659230219a29435a06254dc**da2228d80funtil
>  I'm done with the refactoring (then, I'll use different branches and
> be more clean in my commits and history)
> Tests are aligned with the current direct proxies strawman. (not sure I'm
> 100% up-to-date when it comes to the enumerate trap signature, I'll have to
> check)
>
>
>  generators especially). I intend to start creating test cases for these
>> features as soon as I finish fixing out the remaining test262 tests that
>> Continuum fails.
>>
> I'd like to point out that I've sent feedback [1][2][3] after my work on
> the test suite. I'm more and more convinced that writing test suites is an
> excellent opportunity to see corners that weren't seen before. I'd say that
> this exercise is complementary to the spec editing work based on which
> Allen and wiki.ecmascript editors regularly sends feedback to the list too.
> I've posted (and Andreas before me) about built-in algorithms being frozen
> as soon as proxies are released. I take writing tests for that as an
> opportunity to carefully review these algorithms and maybe suggest changes
> if applicable. I don't think anyone really want to spend time reading
> algorithms and imagining how proxies would interact with them. Writing
> tests is a good excuse to do this exercise.
> And... there will be a test suite as outcome, but the way I see it, the
> process of writing the test suite is actually more important than the
> outcome itself.
>
> So, yes, if you do want to write tests for any feature, I strongly
> encourage you to do so. I strongly encourage anyone reading this message to
> do so.
>
> David
>
> [1] https://mail.mozilla.org/**pipermail/es-discuss/2012-**
> September/024808.html
> [2] https://mail.mozilla.org/**pipermail/es-discuss/2012-**
> October/02.html
> [3] https://mail.mozilla.org/**pipermail/es-discuss/2012-**
> September/025032.html
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Bug in regular expression semantics?

[Joshua Cranmer]

I am currently working on building an executable version of the 
semantics of regular expression pattern matching, and I think I've found 
in a bug in how they are specified in both the released version of 
ECMA-262 and the latest working draft.


In §15.10.2.5, it says that:
The production Term :: Assertion evaluates by returning an internal 
Matcher closure that takes two arguments, a State x and a Continuation 
c, and performs the following:

1. Evaluate Assertion to obtain an AssertionTester t.
[ ... ]

However, the definition of the negative and positive lookahead 
assertions in §15.10.2.6 do not return AssertionTesters (like the ^, $, 
\b, and \B assertions do) but matchers:

The production Assertion :: ( ? = Disjunction ) evaluates as follows:
1. Evaluate Disjunction to obtain a Matcher m.
2. Return an internal Matcher closure that takes two arguments, a State 
x and a Continuation c, and performs the following steps:
   1. Let d be a Continuation that always returns its State argument as 
a successful MatchResult.

   2. Call m(x, d) and let r be its result.
   3. If r is failure, return failure.
   4. Let y be r's State.
   5. Let cap be y's captures internal array.
   6. Let xe be x's endIndex.
   7. Let z be the State (xe, cap).
   8. Call c(z) and return its result.

--
Joshua Cranmer

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

Re: Continuum - ES6 virtual machine built in ES3

[David Bruant]

Le 11/12/2012 21:46, Brandon Benvie a écrit :

http://github.com/benvie/continuum - project
http://benvie.github.com/continuum - debugger
npm module 'continuum'

Continuum is a virtual machine for executing ES6 code (the spec is 
rapidly iterating so many things need updating). It's written in ES3 
and targets a baseline of IE8 (debugger included). With a small amount 
of additional work it could run reliably in engines as old as IE6, but 
this hasn't been a priority.


Almost all ES6 features are supported to some degree: modules, 
Proxy/Reflect, Map/Set/WeakMap, generators, 
destructuring/spread/rest/default params, __proto__, classes, Symbols, 
Typed Arrays/DataView (all features work in any host engine that can 
run Continuum).

Awesome :-)

The only remaining features which are unimplemented are tail call 
optimization (incomplete and disabled pending some changes), array 
comprehensions, generator expressions, and new parts of the binary 
data API (structs, etc.). Some features are incomplete and potentially 
buggy, especially ones which are completely new and have a lot of 
surface area not covered by test262 (proxies

I've started a test suite at https://github.com/DavidBruant/ProxyTests
It was just for me at first, so I started with QUnit (I'll probably 
change that eventually). My end goal is to write test for the internals 
of built-in algorithms; proxies exposes them, I'd like to be sure that 
there is some minimum test suite that shows spec deviations for these 
(and why not see if proxies make engines crash when applying built-in 
algorithms)

There is only one branch and I'm in the middle of a refactoring :-s
I think you can start with this commit 
https://github.com/DavidBruant/ProxyTests/commit/ea53adb659230219a29435a06254dcda2228d80f 
until I'm done with the refactoring (then, I'll use different branches 
and be more clean in my commits and history)
Tests are aligned with the current direct proxies strawman. (not sure 
I'm 100% up-to-date when it comes to the enumerate trap signature, I'll 
have to check)


generators especially). I intend to start creating test cases for 
these features as soon as I finish fixing out the remaining test262 
tests that Continuum fails.
I'd like to point out that I've sent feedback [1][2][3] after my work on 
the test suite. I'm more and more convinced that writing test suites is 
an excellent opportunity to see corners that weren't seen before. I'd 
say that this exercise is complementary to the spec editing work based 
on which Allen and wiki.ecmascript editors regularly sends feedback to 
the list too.
I've posted (and Andreas before me) about built-in algorithms being 
frozen as soon as proxies are released. I take writing tests for that as 
an opportunity to carefully review these algorithms and maybe suggest 
changes if applicable. I don't think anyone really want to spend time 
reading algorithms and imagining how proxies would interact with them. 
Writing tests is a good excuse to do this exercise.
And... there will be a test suite as outcome, but the way I see it, the 
process of writing the test suite is actually more important than the 
outcome itself.


So, yes, if you do want to write tests for any feature, I strongly 
encourage you to do so. I strongly encourage anyone reading this message 
to do so.


David

[1] https://mail.mozilla.org/pipermail/es-discuss/2012-September/024808.html
[2] https://mail.mozilla.org/pipermail/es-discuss/2012-October/02.html
[3] https://mail.mozilla.org/pipermail/es-discuss/2012-September/025032.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Continuum - ES6 virtual machine built in ES3

[Brandon Benvie]

http://github.com/benvie/continuum - project
http://benvie.github.com/continuum - debugger
npm module 'continuum'

Continuum is a virtual machine for executing ES6 code (the spec is rapidly
iterating so many things need updating). It's written in ES3 and targets a
baseline of IE8 (debugger included). With a small amount of additional work
it could run reliably in engines as old as IE6, but this hasn't been a
priority.

Almost all ES6 features are supported to some degree: modules,
Proxy/Reflect, Map/Set/WeakMap, generators,
destructuring/spread/rest/default params, __proto__, classes, Symbols,
Typed Arrays/DataView (all features work in any host engine that can run
Continuum). The only remaining features which are unimplemented are tail
call optimization (incomplete and disabled pending some changes), array
comprehensions, generator expressions, and new parts of the binary data API
(structs, etc.). Some features are incomplete and potentially buggy,
especially ones which are completely new and have a lot of surface area not
covered by test262 (proxies, generators especially). I intend to start
creating test cases for these features as soon as I finish fixing out the
remaining test262 tests that Continuum fails.

The engine is currently completely unoptimized so performance is abysmal. I
intend to persue optimizations following a strategy similar to how PyPy
works, in tracing the interpreter and runtime and creating a JIT "compiler"
that compiles with the host engine as the target and asm.js type code as
the generated output. This is a parallel to PyPy's usage of RPython -> C.

In the process of filling out spec features, I have also been working on a
number of special APIs for using information from the runtime for debugging
purposes, mocking, and integration with the host environment. I'm also
working on the foundation for a development environment built with
Continuum as its core. These things may be found in the experimental folder
of the repo.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.define ==> Object.mixin??

[Andrea Giammarchi]

what I think is a very valid use case for mixins based on ES5 features

var MixIt = Object.defineProperties({}, {
  name: {
enumerable: true,
get: function () {
  // notify or do stuff
  return this._name;
},
set: function (_name) {
  // notify or do stuff
  this._name = _name;
}
  },
  _name: {
writable: true
  }
});

while super is unknown concept in ES5 but if de-sugared as
Constructor.prototype.method.call(this, argN) in ES6 then is implicitly
valid/doesn't need to be modified?

br


On Tue, Dec 11, 2012 at 10:29 AM, Rick Waldron wrote:

>
>
>
> On Tue, Dec 11, 2012 at 1:27 PM, Allen Wirfs-Brock 
> wrote:
>
>> >> 2) It needs to rebind super references
>> >> 3) I don't see any reason that it should be restricted to enumerable
>> >> properties. If the intend is to deprecate enumerable along with for-in
>> then
>> >> we should be adding new functionality that is sensitive to the state
>> of the
>> >> enumerable attribute.
>> >
>> > "should not"?
>>
>> Right, should not!
>>
>
> To clarify, I assumed you meant "should not", based on the rationale and
> that is what I was agreeing to.
>
> Rick
>
>
> ___
> 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: Object.define ==> Object.mixin??

[Allen Wirfs-Brock]

On Dec 11, 2012, at 10:19 AM, Andrea Giammarchi wrote:

> Agreed, getOwnPropertyNames is way more appropriate if the topic is: use all 
> ES5 features for mixins too.
> 
> Also, the Nicolas example is potentially disaster prone, not in that specific 
> form, but in the way a getter with private scope access could be.
> 
> Imagine many objects using that specific object as mixin with that name 
> getter, if there was a setter too the first one that will use it will 
> overwrite the returned value for all other objects.
> 
> I think propertie swith getters and setters will cause as many headaches as 
> objects and arrays in function prototypes did before already but hey, if you 
> know what you are doing, I believe there's no other solution for "universally 
> capable mixin method"

I had a proposal for creating accessors that would only over-ride half of an 
inherited get/set pair: 
http://wiki.ecmascript.org/doku.php?id=harmony:object_initialiser_super#super_in_accessor_property_definitions
 

I let it fade away because, 1) it was kind of ugly, and 2) there were other 
more important things to put energy into.

Allen



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

Re: Object.define ==> Object.mixin??

[Rick Waldron]

On Tue, Dec 11, 2012 at 1:27 PM, Allen Wirfs-Brock wrote:

> >> 2) It needs to rebind super references
> >> 3) I don't see any reason that it should be restricted to enumerable
> >> properties. If the intend is to deprecate enumerable along with for-in
> then
> >> we should be adding new functionality that is sensitive to the state of
> the
> >> enumerable attribute.
> >
> > "should not"?
>
> Right, should not!
>

To clarify, I assumed you meant "should not", based on the rationale and
that is what I was agreeing to.

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

Re: Object.define ==> Object.mixin??

[Allen Wirfs-Brock]

On Dec 11, 2012, at 10:19 AM, Mark S. Miller wrote:

> On Tue, Dec 11, 2012 at 10:12 AM, Allen Wirfs-Brock
>  wrote:
>> 
>> 
>> Except,
>> 1) It needs to iterate own keys, not just string valued property names so it
>> will pick up properties whose keys are symbols
>> 2) It needs to rebind super references
>> 3) I don't see any reason that it should be restricted to enumerable
>> properties. If the intend is to deprecate enumerable along with for-in then
>> we should be adding new functionality that is sensitive to the state of the
>> enumerable attribute.
> 
> "should not"?

Right, should not!

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

Re: Object.define ==> Object.mixin??

[Rick Waldron]

On Tue, Dec 11, 2012 at 1:12 PM, Allen Wirfs-Brock wrote:

>
> On Dec 11, 2012, at 10:00 AM, Rick Waldron wrote:
>
>
>
>
> On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock  > wrote:
>
>> I'm the past we discussed issues surrounding the semantic differences
>> between "put" and "define" and we've agreed to include Object.assign in
>> ES6.  We have also discussed Object.define but have not yet made a decision
>> to include it.
>>
>> Nicholas Zaka recently posted a short article that addresses issues
>> relating to the assign/define distinction
>> http://www.nczonline.net/blog/2012/12/11/are-your-mixins-ecmascript-5-compatible/
>> as they already surface in ES5.
>>
>> For me, this article reenforces that we really need to have something
>> like Object.define in ES6.
>>
>> It also made me think that perhaps Object.mixin might be a more intuitive
>> name for such a function.
>>
>
> This name is certainly more real-word-friendly.
>
> The example code that follows "A pure ECMAScript 5 version of mixin()
> would be:" is basically what I imagined Object.define would be, but with a
> slight modification in that Object.assign returns the target object, so
> should Object.mixin:
>
>
> Except,
> 1) It needs to iterate own keys, not just string valued property names so
> it will pick up properties whose keys are symbols
> 2) It needs to rebind super references
> 3) I don't see any reason that it should be restricted to enumerable
> properties. If the intend is to deprecate enumerable along with for-in then
> we should be adding new functionality that is sensitive to the state of the
> enumerable attribute.
>

Agreed with all three points.


Rick


>
> Allen
>
>
>
>
>
> Object.mixin = function(receiver, supplier) {
>   return Object.keys(supplier).reduce(function(receiver, property) {
> return Object.defineProperty(
>   receiver, property, Object.getOwnPropertyDescriptor(supplier,
> property)
> );
>   }, receiver);
> };
>
>
> var a = {}, name = "Rick";
>
> var b = Object.mixin(a, {
>   get name() {
>  return name;
>   }
> });
>
> console.log( a.name ); // "Rick"
> console.log( b.name ); // "Rick"
> console.log( a === b ); // true
>
>
> Rick
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.define ==> Object.mixin??

[Mark S. Miller]

On Tue, Dec 11, 2012 at 10:12 AM, Allen Wirfs-Brock
 wrote:
>
> On Dec 11, 2012, at 10:00 AM, Rick Waldron wrote:
>
>
>
>
> On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock 
> wrote:
>>
>> I'm the past we discussed issues surrounding the semantic differences
>> between "put" and "define" and we've agreed to include Object.assign in ES6.
>> We have also discussed Object.define but have not yet made a decision to
>> include it.
>>
>> Nicholas Zaka recently posted a short article that addresses issues
>> relating to the assign/define distinction
>> http://www.nczonline.net/blog/2012/12/11/are-your-mixins-ecmascript-5-compatible/
>> as they already surface in ES5.
>>
>> For me, this article reenforces that we really need to have something like
>> Object.define in ES6.
>>
>> It also made me think that perhaps Object.mixin might be a more intuitive
>> name for such a function.
>
>
> This name is certainly more real-word-friendly.
>
> The example code that follows "A pure ECMAScript 5 version of mixin() would
> be:" is basically what I imagined Object.define would be, but with a slight
> modification in that Object.assign returns the target object, so should
> Object.mixin:
>
>
> Except,
> 1) It needs to iterate own keys, not just string valued property names so it
> will pick up properties whose keys are symbols
> 2) It needs to rebind super references
> 3) I don't see any reason that it should be restricted to enumerable
> properties. If the intend is to deprecate enumerable along with for-in then
> we should be adding new functionality that is sensitive to the state of the
> enumerable attribute.

"should not"?


>
> Allen
>
>
>
>
>
> Object.mixin = function(receiver, supplier) {
>   return Object.keys(supplier).reduce(function(receiver, property) {
> return Object.defineProperty(
>   receiver, property, Object.getOwnPropertyDescriptor(supplier,
> property)
> );
>   }, receiver);
> };
>
>
> var a = {}, name = "Rick";
>
> var b = Object.mixin(a, {
>   get name() {
> return name;
>   }
> });
>
> console.log( a.name ); // "Rick"
> console.log( b.name ); // "Rick"
> console.log( a === b ); // true
>
>
> Rick
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



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

Re: Object.define ==> Object.mixin??

[Andrea Giammarchi]

Agreed, getOwnPropertyNames is way more appropriate if the topic is: use
all ES5 features for mixins too.

Also, the Nicolas example is potentially disaster prone, not in that
specific form, but in the way a getter with private scope access could be.

Imagine many objects using that specific object as mixin with that name
getter, if there was a setter too the first one that will use it will
overwrite the returned value for all other objects.

I think propertie swith getters and setters will cause as many headaches as
objects and arrays in function prototypes did before already but hey, if
you know what you are doing, I believe there's no other solution for
"universally capable mixin method"

br


On Tue, Dec 11, 2012 at 10:12 AM, Allen Wirfs-Brock
wrote:

>
> On Dec 11, 2012, at 10:00 AM, Rick Waldron wrote:
>
>
>
>
> On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock  > wrote:
>
>> I'm the past we discussed issues surrounding the semantic differences
>> between "put" and "define" and we've agreed to include Object.assign in
>> ES6.  We have also discussed Object.define but have not yet made a decision
>> to include it.
>>
>> Nicholas Zaka recently posted a short article that addresses issues
>> relating to the assign/define distinction
>> http://www.nczonline.net/blog/2012/12/11/are-your-mixins-ecmascript-5-compatible/
>> as they already surface in ES5.
>>
>> For me, this article reenforces that we really need to have something
>> like Object.define in ES6.
>>
>> It also made me think that perhaps Object.mixin might be a more intuitive
>> name for such a function.
>>
>
> This name is certainly more real-word-friendly.
>
> The example code that follows "A pure ECMAScript 5 version of mixin()
> would be:" is basically what I imagined Object.define would be, but with a
> slight modification in that Object.assign returns the target object, so
> should Object.mixin:
>
>
> Except,
> 1) It needs to iterate own keys, not just string valued property names so
> it will pick up properties whose keys are symbols
> 2) It needs to rebind super references
> 3) I don't see any reason that it should be restricted to enumerable
> properties. If the intend is to deprecate enumerable along with for-in then
> we should be adding new functionality that is sensitive to the state of the
> enumerable attribute.
>
> Allen
>
>
>
>
>
> Object.mixin = function(receiver, supplier) {
>   return Object.keys(supplier).reduce(function(receiver, property) {
> return Object.defineProperty(
>   receiver, property, Object.getOwnPropertyDescriptor(supplier,
> property)
> );
>   }, receiver);
> };
>
>
> var a = {}, name = "Rick";
>
> var b = Object.mixin(a, {
>   get name() {
>  return name;
>   }
> });
>
> console.log( a.name ); // "Rick"
> console.log( b.name ); // "Rick"
> console.log( a === b ); // true
>
>
> Rick
>
>
>
> ___
> 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: Object.define ==> Object.mixin??

[Allen Wirfs-Brock]

On Dec 11, 2012, at 10:00 AM, Rick Waldron wrote:

> 
> 
> 
> On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock  
> wrote:
> I'm the past we discussed issues surrounding the semantic differences between 
> "put" and "define" and we've agreed to include Object.assign in ES6.  We have 
> also discussed Object.define but have not yet made a decision to include it.
> 
> Nicholas Zaka recently posted a short article that addresses issues relating 
> to the assign/define distinction 
> http://www.nczonline.net/blog/2012/12/11/are-your-mixins-ecmascript-5-compatible/
>   as they already surface in ES5.
> 
> For me, this article reenforces that we really need to have something like 
> Object.define in ES6.
> 
> It also made me think that perhaps Object.mixin might be a more intuitive 
> name for such a function.
> 
> This name is certainly more real-word-friendly.
> 
> The example code that follows "A pure ECMAScript 5 version of mixin() would 
> be:" is basically what I imagined Object.define would be, but with a slight 
> modification in that Object.assign returns the target object, so should 
> Object.mixin:

Except,
1) It needs to iterate own keys, not just string valued property names so it 
will pick up properties whose keys are symbols
2) It needs to rebind super references
3) I don't see any reason that it should be restricted to enumerable 
properties. If the intend is to deprecate enumerable along with for-in then we 
should be adding new functionality that is sensitive to the state of the 
enumerable attribute.

Allen




> 
> Object.mixin = function(receiver, supplier) {
>   return Object.keys(supplier).reduce(function(receiver, property) {
> return Object.defineProperty(
>   receiver, property, Object.getOwnPropertyDescriptor(supplier, property)
> );
>   }, receiver);
> };
> 
> 
> var a = {}, name = "Rick";
> 
> var b = Object.mixin(a, {
>   get name() {
> return name;
>   }
> });
> 
> console.log( a.name ); // "Rick"
> console.log( b.name ); // "Rick"
> console.log( a === b ); // true
> 
> 
> Rick
> 

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

Re: Object.define ==> Object.mixin??

[Rick Waldron]

On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock
wrote:

> I'm the past we discussed issues surrounding the semantic differences
> between "put" and "define" and we've agreed to include Object.assign in
> ES6.  We have also discussed Object.define but have not yet made a decision
> to include it.
>
> Nicholas Zaka recently posted a short article that addresses issues
> relating to the assign/define distinction
> http://www.nczonline.net/blog/2012/12/11/are-your-mixins-ecmascript-5-compatible/
> as they already surface in ES5.
>
> For me, this article reenforces that we really need to have something like
> Object.define in ES6.
>
> It also made me think that perhaps Object.mixin might be a more intuitive
> name for such a function.
>

This name is certainly more real-word-friendly.

The example code that follows "A pure ECMAScript 5 version of mixin() would
be:" is basically what I imagined Object.define would be, but with a slight
modification in that Object.assign returns the target object, so should
Object.mixin:

Object.mixin = function(receiver, supplier) {
  return Object.keys(supplier).reduce(function(receiver, property) {
return Object.defineProperty(
  receiver, property, Object.getOwnPropertyDescriptor(supplier,
property)
);
  }, receiver);
};


var a = {}, name = "Rick";

var b = Object.mixin(a, {
  get name() {
return name;
  }
});

console.log( a.name ); // "Rick"
console.log( b.name ); // "Rick"
console.log( a === b ); // true


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

Re: Object.define ==> Object.mixin??

[Brandon Benvie]

Wholeheartedly agree with this. For library authoring it's a necessity, so
a define like function is always the first thing in any .js file I make.
The need for library authors is obvious but if I recall the conclusion was
that those authors would be able to handle it themselves and to push off on
codifying it into the language so popular patterns could emerge. I think
that article well outlines how this is actually a need and concern in
authoring of non-library code. Specifically, accessors are a part of the
language (and are going to see more and more use as ES5 becomes the
baseline) and in order to correctly handle those for structure-copying you
must use descriptor-aware functions.


On Tue, Dec 11, 2012 at 12:28 PM, Allen Wirfs-Brock
wrote:

> I'm the past we discussed issues surrounding the semantic differences
> between "put" and "define" and we've agreed to include Object.assign in
> ES6.  We have also discussed Object.define but have not yet made a decision
> to include it.
>
> Nicholas Zaka recently posted a short article that addresses issues
> relating to the assign/define distinction
> http://www.nczonline.net/blog/2012/12/11/are-your-mixins-ecmascript-5-compatible/
> as they already surface in ES5.
>
> For me, this article reenforces that we really need to have something like
> Object.define in ES6.
>
> It also made me think that perhaps Object.mixin might be a more intuitive
> name for such a function.
>
> 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

Object.define ==> Object.mixin??

[Allen Wirfs-Brock]

I'm the past we discussed issues surrounding the semantic differences between 
"put" and "define" and we've agreed to include Object.assign in ES6.  We have 
also discussed Object.define but have not yet made a decision to include it.

Nicholas Zaka recently posted a short article that addresses issues relating to 
the assign/define distinction 
http://www.nczonline.net/blog/2012/12/11/are-your-mixins-ecmascript-5-compatible/
  as they already surface in ES5.

For me, this article reenforces that we really need to have something like 
Object.define in ES6.

It also made me think that perhaps Object.mixin might be a more intuitive name 
for such a function.

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

Re: On dropping @names

[Andreas Rossberg]

On 10 December 2012 21:59, Claus Reinke  wrote:
>> Second, it doesn't eliminate the need for temporal dead zones at all.
>
> You could well be right, and I might have been misinterpreting what
> "temporal dead zone" (tdz) means.
> For a letrec, I expect stepwise-refinement-starting-from-undefined
> semantics, so I can use a binding anywhere in scope but may or may
> not get a value for it. While the tdz seems to stipulate that a binding for
> a variable in scope doesn't really exist and may not be accessed until its
> binding (explicit or implicitly undefined) statement is evaluated.

Not sure what you mean by
"stepwise-refinement-starting-from-undefined". JavaScript is both
eager and impure, and there is no tradition of imposing syntactic
restrictions on recursive bindings. Consequently, any binding can have
effects, and the semantics must be sequentialised according to textual
order. Short of sophisticated static analysis (which we can't afford
in a jitted language), there is no way to prevent erroneous forward
accesses from being observable at runtime.

The question, then, boils down to what the observation should be: a
runtime error (aka temporal dead zone) or 'undefined'. Given that
choice, the former is superior in almost every way, because the latter
prevents subtle initialisation errors from being caught early, and is
not an option for most binding forms anyway.

>> So what does it gain? The model we have now simply is that every scope is
>> a letrec (which is how JavaScript has always worked, albeit
>> with a less felicitous notion of scope).
>
> That is a good way of looking at it. So if there are any statements
> mixed in between the definitions, we simply interpret them as
> definitions (with side-effecting values) of unused bindings, and
>
> { let x = 0;
>  let z = [x,y]; // (*)
>  x++;
>  let y = x;  let __ = console.log(z);
> }
>
> is interpreted as
>
> { let x = 0;
>  let z = [x,y]; // (*)
>  let _ = x++;
>  let y = x;
>  let __ = console.log(z);
> }

Exactly. At least that's my preferred way of looking at it.

> What does it mean here that y is *dead* at (*), *dynamically*?
> Is it just that y at (*) is undefined, or does the whole construct throw a
> ReferenceError, or what?

Throw, see above.

> If tdz is just a form of saying that y is undefined at (*), then I can
> read the whole block as a letrec construct. If y cannot be used until its
> binding initializer statement has been executed, then I seem to have a
> sequence of statements instead.

It inevitably is an _impure_ letrec, which is where the problems come in.

> Of course, letrec in a call-by-value language with side-effects is tricky.
> And I assume that tdz is an attempt to guard against unwanted surprises. But
> for me it is a surprise that not only can side-effects on the right-hand
> sides modify bindings (x++), but that bindings are interpreted as
> assignments that bring in variables from the dead.

They are initialisations, not assignments. The difference, which is
present in other popular languages as well, is somewhat important,
especially wrt immutable bindings. Furthermore, temporal dead zone
also applies to assignments. So at least, side effects (which cannot
easily be disallowed) can only modify bindings after they have been
initialised.

None of these problems would go away by having explicit recursion.
Unless you impose far more severe restrictions.

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