Re: about lightweight traits

[Andrea Giammarchi]

So we agree traits are not classes and notions, as well as functionality,
is different. Then why would you us `class` to define a trait?

How are you going to recognize them?

I have a library that works already out of the box with traits but these
are not classes, just objects that will enrich classes.

Overriding methods means having a warning in console, instead of throwing,
and nothing else.
You compose whatever you want, order of defined mixins/traits matters, as
well as eventual initialization of each trait.

The latter one, is available already once each instance is defined, inside
the constructor.
This works to me, and I'd rather avoid the burden to walk all inheritance
chain if I have to accept classes too instead of objects, but I wouldn't
mind implementing it as long as I understand why that's a good thing to
have in JS.

Best Regards


On Thu, Feb 12, 2015 at 9:28 PM, Luke Scott  wrote:

> Traits are different than classical inheritance. They simply copy
> functionality into a class as if the method was actually defined in the
> class. It isn’t inheritance. It allows you to DRY.
>
> A real world example in my ES6 project:
>
> - Node
> - Element extends Node
> - Field extends Element
> - TextField extends Element
> - Select extends Element, mixin Parent
> - Option extends Element
> - Fieldset extends Element, mixin Parent
>
> In this case (subset of my class structure) a Fieldset has child
> Nodes/Elements/Fields. A Field and TextField does not have children. Yet,
> Select has specific child nodes. I use a trait to mixin the Parent trait to
> reuse functionality. Select is a parent because it has the trait, but the
> parent class Field is not a parent. In my case it makes no sense to
> re-implement that in Select, especially when having the Parent trait means
> something when building something like a lookup table.
>
> I think it’s important to note that a trait knows very little of the class
> that implements it. For example I may mixin Parent into Select or Fieldset,
> but I restrict myself to methods found in Node (my base class) to be able
> to use the trait in any situation. If I need functionality from another
> trait, I mixin the other trait to make one trait.
>
> On Feb 12, 2015, at 12:07 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
> So you are saying we can just forget about extends keyword and use mixin
> instead for everything, right?
> --
> From: Alex Russell 
> Sent: ‎12/‎02/‎2015 20:05
> To: Andrea Giammarchi 
> Cc: Luke Scott ; es-discuss@mozilla.org
> Subject: Re: about lightweight traits
>
> Traits as class make perfect sense when you consider that classes are
> functions and so are traits.
>
> On Thu, Feb 12, 2015 at 10:27 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> this thousand times ... Traits as class makes no sense to me indeed and
>> Mark example shows plain objects passed as Trait.create ... that works just
>> fine, except some trait initialization, which should not be a constructor,
>> could be used too.
>>
>> Is there any other language that uses same classical OOP classes as
>> traits too? It really does not feel right to me.
>>
>> Btw, reason I'm asking is because somebody else asked, I'm really OK to
>> not rush and wait to see how it goes when it's the right time.
>>
>> Best Regards
>>
>> On Thu, Feb 12, 2015 at 6:32 PM, Luke Scott  wrote:
>>
>>>
>>> On Feb 12, 2015, at 8:35 AM, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
>>> Without going down full specification/implementation details, does
>>> anyone believe that classes should/could be used, in the future, as
>>> traits/mixins too?
>>>
>>> I find that an anty pattern.
>>>
>>> I think traits should be just plain objects with an initializer or some
>>> special object flagged as trait and I'd rather leave inheritance and
>>> classes features outside this future feature.
>>>
>>> Thoughts? Thanks!
>>>
>>>
>>> I would agree with that. I had a trait implementation that used classes
>>> as traits, and it caused a lot of problems, especially since classes have
>>> constructors. Traits should not have constructors. I have since updated my
>>> implementation to use plain objects.
>>>
>>> This is what I am using now:
>>> https://gist.github.com/lukescott/36453a75c39c539f5c7d
>>>
>>> ___
>>> 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
>>
>>
>
>
> ___
> 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: about lightweight traits

[Andrea Giammarchi]

Luke, answering in order:

1. defining order, first come, first serve ... same as everything else on
daily usage (events, Array of callbacks, etc)

2. You do not ever pass parameter to them, parameters are constructors
matters, traits should be independent and unaware of constructors arguments
otherwise you loose portability.
A trait should be able to work and enrich any sort of class, not just some
specific one it has no notion about.

3. before everything else, since these should be stand-alone behaviors
unrelated with constructors

All marked as IMO, of course :-)


On Thu, Feb 12, 2015 at 9:33 PM, Luke Scott  wrote:

>
> > On Feb 12, 2015, at 12:11 PM, Domenic Denicola  wrote:
> >
> > From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> Benjamin Gruenbaum
> >
> >> We have `Object.assign` that works fantastically for most classic trait
> use cases.
> >
> > Well, actually, it works extremely poorly. The old (now dead or
> deferred) `Object.mixin`, once called `Object.define`, is a better fit. But
> it still fails to account for a couple things, off the top of my head:
> >
> > - Being able to add custom initialization logic to the class constructor
> when "mixing in" a trait. You can construct a custom protocol around this,
> but (a) that means the class you're mixing in to needs to be aware of the
> protocol; (b) everyone needs to agree on a protocol across the ecosystem.
> > - Pretty much anything to do with private state doesn't work anymore.
>
> The biggest issues of trait initializers are (constructors) are:
>
> - What order do you call them in.
> - How do you pass in parameters into them.
> - They would need to be called by the class constructor. Does this happen
> at the beginning or end?
>
> I would argue that traits should not have initializers. It’s much easier
> to do something like this:
>
> trait Trait1 {
> initTrait1() {
> // this is a regular method
> // init trait here
>}
> }
>
> class Trait1 {
> mixin Trait1;
>
> constructor() {
> // do work here…
> this.initTrait1()
> // do more work here...
> }
> }
>
> This kind of pattern makes initializing traits more intentional and leaves
> out any assumptions of what the correct order would be. And not all traits
> need initializers, so it leaves out a lot of complexity.
>
> ___
> 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: about lightweight traits

[Andrea Giammarchi]

Luke, forgot one detail: you do not explicitly initialize traits, these are
initialized if these have an `init` or `initialize` method defined, and
before the constructor is executed. So, using you example code:

```js

trait Trait1 {
initt() {
this.trait1Data = {what:'ever'};
   }
}

class Trait1 {
mixin Trait1;

constructor() {
console.log(this.trait1Data);
// {what:'ever'}
}
}


```

That makes them really portable, the class is instantly aware of them since
it used them as mixin, but traits are fully independent.

Do you need a lazy trait? Then you can expose an explicit method to
set-it-up and invoke it whenever you want in your constructor.

Does any of this make sense? It works already in some case of mine :-)



On Thu, Feb 12, 2015 at 9:42 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> Luke, answering in order:
>
> 1. defining order, first come, first serve ... same as everything else on
> daily usage (events, Array of callbacks, etc)
>
> 2. You do not ever pass parameter to them, parameters are constructors
> matters, traits should be independent and unaware of constructors arguments
> otherwise you loose portability.
> A trait should be able to work and enrich any sort of class, not just some
> specific one it has no notion about.
>
> 3. before everything else, since these should be stand-alone behaviors
> unrelated with constructors
>
> All marked as IMO, of course :-)
>
>
> On Thu, Feb 12, 2015 at 9:33 PM, Luke Scott  wrote:
>
>>
>> > On Feb 12, 2015, at 12:11 PM, Domenic Denicola  wrote:
>> >
>> > From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
>> Benjamin Gruenbaum
>> >
>> >> We have `Object.assign` that works fantastically for most classic
>> trait use cases.
>> >
>> > Well, actually, it works extremely poorly. The old (now dead or
>> deferred) `Object.mixin`, once called `Object.define`, is a better fit. But
>> it still fails to account for a couple things, off the top of my head:
>> >
>> > - Being able to add custom initialization logic to the class
>> constructor when "mixing in" a trait. You can construct a custom protocol
>> around this, but (a) that means the class you're mixing in to needs to be
>> aware of the protocol; (b) everyone needs to agree on a protocol across the
>> ecosystem.
>> > - Pretty much anything to do with private state doesn't work anymore.
>>
>> The biggest issues of trait initializers are (constructors) are:
>>
>> - What order do you call them in.
>> - How do you pass in parameters into them.
>> - They would need to be called by the class constructor. Does this happen
>> at the beginning or end?
>>
>> I would argue that traits should not have initializers. It’s much easier
>> to do something like this:
>>
>> trait Trait1 {
>> initTrait1() {
>> // this is a regular method
>> // init trait here
>>}
>> }
>>
>> class Trait1 {
>> mixin Trait1;
>>
>> constructor() {
>> // do work here…
>> this.initTrait1()
>> // do more work here...
>> }
>> }
>>
>> This kind of pattern makes initializing traits more intentional and
>> leaves out any assumptions of what the correct order would be. And not all
>> traits need initializers, so it leaves out a lot of complexity.
>>
>> ___
>> 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: about lightweight traits

[Andrea Giammarchi]

It looks like we agree traits are **not** classes so that classes should
not be used or accepted as traits ... which is already an answer to my
initial question.

Other "problems"

init is a special case, as constructor is. You don't need a constructor to
create an instance, you might not need to initialize a trait in order to be
used.

However, trait brings functionality, and this should be consistent. If a
class forgets to initialize a trait this should work regardless. If a class
does not need a constructor, traits should be usable/initialized
automatically regardless.

This is the implicit nature of my proposed `init` . To go your way,
initTrait1() as lazy, explicit method you can **always** do that.

If a trait requires some specific info during initialization, you can
always use `this.initTrait1(info)` inside any class method, but that's
something different from the initial, optional, setup such trait might
need, a setup that, if present, will be granted inside the implicit `init`

What happens inside is also not a class responsibility, class simply has
enriched prototype with methods, when that init should occur is not
necessarily a class matter while those methods should instead work ASAP. An
implicit initializer covers already 100% of cases, it can be absent and go
lazy initializer any time.


Last question: would an init override another init? Well, using as little
as possible stand-alone logic to compose traits, I haven't personally found
a case when Trait2 mixins Trait1 but I believe that's how I'd go

```js
trait Trait2 {
  mixin Trait1;
  init() {
Trait1.init.call(this);
this.trait2Data = {any:'thing'};
  }
}
```

init is transparent once mixed in, but reachable regardless explicitly.
Same as it is for constructor, nothing new to learn here, we are used to
`OtherClass.call(this)` now simplified via `super.constructor()`


Last bit of info: all this works already in es-class with traits specified
as objects, here more examples:
https://github.com/WebReflection/es-class/blob/master/FEATURES.md#with

Best Regards




On Thu, Feb 12, 2015 at 10:07 PM, Luke Scott  wrote:

> I know what you’re going for, and I had this in my initial implementation.
> The issue then becomes:
>
> If Trait2 mixes in Trait1, does the init method get replaced? Traits are
> about inserting functionality, not about inheritance. Example:
>
> trait Trait1 {
> init() {
>   // init Trait1
> }
> }
>
> trait Trait2 {
> mixin Trait1;
>
> init() {
> // init Trait 2
> }
> }
>
> class Foo {
> mixin Trait2;
>
> constructor() {
> // do Foo stuff...
> }
> }
>
> So either init is special and the call order is Trait1.init()
> Trait2.init() (while other methods get replaced) or Trait2.init() replaces
> the Trait1.init(). Also since traits are not classes, they cannot call
> super. You also are defying the call stack because trait initializers “just
> happen” internally. There is no trail to step through, unlike classes which
> leaves a trail of breadcrumbs with super() calls.
>
> This version is actually easy to follow:
>
> trait Trait1 {
> initTrait1() {
>   // init Trait1
> }
> }
>
> trait Trait2 {
> mixin Trait1;
>
> initTrait2() {
> this.initTrait1();
> // init Trait 2
> }
> }
>
> class Foo {
> mixin Trait2;
>
> constructor() {
> this.initTrait2();
> // do Foo stuff...
> }
> }
>
> True, each class has to call the custom init methods. But it still
> addresses 95% of the problem: Adding in common functionality that doesn’t
> fit in classical inheritance. Also since some traits may expect to be mixed
> in to a subclass of a certain base, it allows you to call super before the
> trait initializers, and that’s something you already have to do in your
> local constructor, so initializing traits in the same way makes sense.
>
> The only thing extra beyond copying implementation into a class or another
> trait is keeping track of what traits have been mixed in for a “hasTrait”
> check. This isn't necessarily required as you can easily check for a method
> you want to call, but it does allow you to make sure that the method
> belongs to trait and check once for a group of methods.
>
> (This is my ES6 implementation of traits that I’m using now:
> https://gist.github.com/lukescott/36453a75c39c539f5c7d)
>
> On Feb 12, 2015, at 12:47 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
> Luke, forgot one detail: you do not explicitly initialize traits, these
> are initialized if these have an `init` or `initialize` method defined, and
> before the constructor is executed. So, using you example code:
&

Re: Performance of iterator .next() as specified

[Andrea Giammarchi]

+1 and I've raised same concerns 2 years ago [1]

IIRC the outcome was that VM should be good enough to handle objects with
very short lifecycle, I'm still convinced (behind tests) that generators
are overkill for IoT devices (low clock and way lower RAM).

Having always same object per iteration makes sense to me at least until
it's done so that could be just a struct-like `{done: false, value: null}`
object and GC will be happier than ever.

Regards


[1]
http://webreflection.blogspot.co.uk/2013/06/on-harmony-javascript-generators.html

On Sun, Feb 15, 2015 at 10:06 AM, Katelyn Gadd  wrote:

> As specified, iterator .next() seems to be required to return a new
> object instance for each iteration.
>
> In my testing (and in my theory, as an absolute) this is a real
> performance defect in the spec and it will make iterators inferior to
> all other forms of sequence iteration, to the extent that they may end
> up being used very rarely, and developers will be biased away from Map
> and Set as a result.
>
> The issue here is that the new object requirement means that every
> iteration produces GC pressure. I think that past APIs with this
> problem (for example TypedArray.set) have proven that 'a sufficiently
> smart VM can optimize this' is not representative of real VMs or real
> use cases.
>
> In the specific case of .next(), the method returning a new object on
> every iteration does not produce any actual improvement to usability:
> There is no realistic use case that requires saving multiple next()
> results from the same sequence, as the sequence itself represents (at
> least in most cases) a container or generated value sequence that is
> fully reproducible on demand.
>
> I think allowing (or requiring) implementations to return the same
> object instance from every .next() call, or perhaps as a usability
> compromise, reusing a pair of objects on a round-robin basis (so that
> you can keep around the current and prior result) would be a very good
> decision here.
>
> In my testing Map and Set are outperformed by a trivial Object or
> Array based data structure in every case, *despite the fact* that
> using an Object as a Map requires the use of Object.keys() to be able
> to sequentially iterate elements. The cost of iterator.next() in v8
> and spidermonkey is currently extremely profound and profiling shows
> all the time is being spent in object creation and GC. (To be fair,
> self-hosting of iterations might improve on this some.)
>
> Oddly enough, I consider the ES iterator spec to be a big improvement
> over C#'s IEnumerable, in terms of usability/API. But this is an area
> where it is intrinsically worse performance-wise than IEnumerable and
> that's unfortunate.
>
> -kg
> ___
> 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: Performance of iterator .next() as specified

[Andrea Giammarchi]

> Shared mutable result objects

FWIW to me that could be even be a singleton frozen `{done: false, value:
null}` constant during iteration and a new object only once done.

Would this work or speed-up anything at all?




On Mon, Feb 16, 2015 at 2:04 PM, Andreas Rossberg 
wrote:

> On 15 February 2015 at 12:07, Katelyn Gadd  wrote:
>
>> I'm certainly in favor of VMs improving to handle that, and adding
>> pressure for it is good. However, optimizing a TypedArray temporary
>> arg to .set() is a much simpler problem than doing the escape analysis
>> necessary to be certain a .next() result doesn't escape from a calling
>> scope and isn't used after a later next() call. Applying pressure will
>> be a good way to make sure VM authors do the work necessary for this
>> to happen, but if iterators are unacceptably slow in shipping
>> implementations for a year+ I think the odds are good that most
>> shipping software will avoid using them, at which point VM authors
>> will have no reason to optimize for primitives nobody uses. =[
>>
>
> Engines are still ramping up on ES6 features, and most probably haven't
> been able to put much resources into optimisations yet (ES6 is large!). You
> can't compare it to old features that have been tuned for a decade and
> expect equal performance. This situation is unfortunate but unavoidable.
>
> Either way, it doesn't justify cutting corners in the semantics in a naive
> and premature attempt to optimise (which might even harm more highl-level
> optimisations on the long run). Shared mutable result objects would be a
> horrible API with footgun potential, especially when you start to build
> stream abstractions on top. FWIW, this has been discussed at length at some
> of the meetings.
>
> The fixed layout of the iterator object would allow the GC to allocate
>> it cheaply and in the case of values (like ints) it wouldn't need to
>> trace it either - so that helps a lot. But I don't know how realistic
>> those optimizations are in practice.
>>
>
> Not sure what you mean here. Unfortunately, result objects are still
> mutable and extensible, so anything can happen.
>
> /Andreas
>
>
> On 15 February 2015 at 02:36, Andrea Giammarchi
>>  wrote:
>> > +1 and I've raised same concerns 2 years ago [1]
>> >
>> > IIRC the outcome was that VM should be good enough to handle objects
>> with
>> > very short lifecycle, I'm still convinced (behind tests) that
>> generators are
>> > overkill for IoT devices (low clock and way lower RAM).
>> >
>> > Having always same object per iteration makes sense to me at least until
>> > it's done so that could be just a struct-like `{done: false, value:
>> null}`
>> > object and GC will be happier than ever.
>> >
>> > Regards
>> >
>> >
>> > [1]
>> >
>> http://webreflection.blogspot.co.uk/2013/06/on-harmony-javascript-generators.html
>> >
>> > On Sun, Feb 15, 2015 at 10:06 AM, Katelyn Gadd 
>> wrote:
>> >>
>> >> As specified, iterator .next() seems to be required to return a new
>> >> object instance for each iteration.
>> >>
>> >> In my testing (and in my theory, as an absolute) this is a real
>> >> performance defect in the spec and it will make iterators inferior to
>> >> all other forms of sequence iteration, to the extent that they may end
>> >> up being used very rarely, and developers will be biased away from Map
>> >> and Set as a result.
>> >>
>> >> The issue here is that the new object requirement means that every
>> >> iteration produces GC pressure. I think that past APIs with this
>> >> problem (for example TypedArray.set) have proven that 'a sufficiently
>> >> smart VM can optimize this' is not representative of real VMs or real
>> >> use cases.
>> >>
>> >> In the specific case of .next(), the method returning a new object on
>> >> every iteration does not produce any actual improvement to usability:
>> >> There is no realistic use case that requires saving multiple next()
>> >> results from the same sequence, as the sequence itself represents (at
>> >> least in most cases) a container or generated value sequence that is
>> >> fully reproducible on demand.
>> >>
>> >> I think allowing (or requiring) implementations to return the same
>> >> object instance from every .next() call, or perhaps as a usability
>> >> compromise,

Re: Performance of iterator .next() as specified

[Andrea Giammarchi]

then frozen `{done: false}` without even the `value` property ... Would
this work or speed-up anything at all?

On Mon, Feb 16, 2015 at 2:32 PM, Andreas Rossberg 
wrote:

> On 16 February 2015 at 15:21, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> > Shared mutable result objects
>>
>> FWIW to me that could be even be a singleton frozen `{done: false, value:
>> null}` constant during iteration and a new object only once done.
>>
>> Would this work or speed-up anything at all?
>>
>
> Frozen value null? I don't understand. You'd get the actual values from...
> where?
>
> /Andreas
>
>
> On Mon, Feb 16, 2015 at 2:04 PM, Andreas Rossberg 
>> wrote:
>>
>>> On 15 February 2015 at 12:07, Katelyn Gadd  wrote:
>>>
>>>> I'm certainly in favor of VMs improving to handle that, and adding
>>>> pressure for it is good. However, optimizing a TypedArray temporary
>>>> arg to .set() is a much simpler problem than doing the escape analysis
>>>> necessary to be certain a .next() result doesn't escape from a calling
>>>> scope and isn't used after a later next() call. Applying pressure will
>>>> be a good way to make sure VM authors do the work necessary for this
>>>> to happen, but if iterators are unacceptably slow in shipping
>>>> implementations for a year+ I think the odds are good that most
>>>> shipping software will avoid using them, at which point VM authors
>>>> will have no reason to optimize for primitives nobody uses. =[
>>>>
>>>
>>> Engines are still ramping up on ES6 features, and most probably haven't
>>> been able to put much resources into optimisations yet (ES6 is large!). You
>>> can't compare it to old features that have been tuned for a decade and
>>> expect equal performance. This situation is unfortunate but unavoidable.
>>>
>>> Either way, it doesn't justify cutting corners in the semantics in a
>>> naive and premature attempt to optimise (which might even harm more
>>> highl-level optimisations on the long run). Shared mutable result objects
>>> would be a horrible API with footgun potential, especially when you start
>>> to build stream abstractions on top. FWIW, this has been discussed at
>>> length at some of the meetings.
>>>
>>> The fixed layout of the iterator object would allow the GC to allocate
>>>> it cheaply and in the case of values (like ints) it wouldn't need to
>>>> trace it either - so that helps a lot. But I don't know how realistic
>>>> those optimizations are in practice.
>>>>
>>>
>>> Not sure what you mean here. Unfortunately, result objects are still
>>> mutable and extensible, so anything can happen.
>>>
>>> /Andreas
>>>
>>>
>>> On 15 February 2015 at 02:36, Andrea Giammarchi
>>>>  wrote:
>>>> > +1 and I've raised same concerns 2 years ago [1]
>>>> >
>>>> > IIRC the outcome was that VM should be good enough to handle objects
>>>> with
>>>> > very short lifecycle, I'm still convinced (behind tests) that
>>>> generators are
>>>> > overkill for IoT devices (low clock and way lower RAM).
>>>> >
>>>> > Having always same object per iteration makes sense to me at least
>>>> until
>>>> > it's done so that could be just a struct-like `{done: false, value:
>>>> null}`
>>>> > object and GC will be happier than ever.
>>>> >
>>>> > Regards
>>>> >
>>>> >
>>>> > [1]
>>>> >
>>>> http://webreflection.blogspot.co.uk/2013/06/on-harmony-javascript-generators.html
>>>> >
>>>> > On Sun, Feb 15, 2015 at 10:06 AM, Katelyn Gadd 
>>>> wrote:
>>>> >>
>>>> >> As specified, iterator .next() seems to be required to return a new
>>>> >> object instance for each iteration.
>>>> >>
>>>> >> In my testing (and in my theory, as an absolute) this is a real
>>>> >> performance defect in the spec and it will make iterators inferior to
>>>> >> all other forms of sequence iteration, to the extent that they may
>>>> end
>>>> >> up being used very rarely, and developers will be biased away from
>>>> Map
>>>> >> and Set as a result.
&

Re: Performance of iterator .next() as specified

[Andrea Giammarchi]

Uhm, early send, so I guess I didn't answer.

Common pattern is to poll.next() a yield until its `done` property is
`true` so that a value can be used.

This is I believe the common case that will create thousands of objects to
be quickly trashed as garbage ... so I was wondering if those are all needed

On Mon, Feb 16, 2015 at 2:38 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> then frozen `{done: false}` without even the `value` property ... Would
> this work or speed-up anything at all?
>
> On Mon, Feb 16, 2015 at 2:32 PM, Andreas Rossberg 
> wrote:
>
>> On 16 February 2015 at 15:21, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> > Shared mutable result objects
>>>
>>> FWIW to me that could be even be a singleton frozen `{done: false,
>>> value: null}` constant during iteration and a new object only once done.
>>>
>>> Would this work or speed-up anything at all?
>>>
>>
>> Frozen value null? I don't understand. You'd get the actual values
>> from... where?
>>
>> /Andreas
>>
>>
>> On Mon, Feb 16, 2015 at 2:04 PM, Andreas Rossberg 
>>> wrote:
>>>
>>>> On 15 February 2015 at 12:07, Katelyn Gadd  wrote:
>>>>
>>>>> I'm certainly in favor of VMs improving to handle that, and adding
>>>>> pressure for it is good. However, optimizing a TypedArray temporary
>>>>> arg to .set() is a much simpler problem than doing the escape analysis
>>>>> necessary to be certain a .next() result doesn't escape from a calling
>>>>> scope and isn't used after a later next() call. Applying pressure will
>>>>> be a good way to make sure VM authors do the work necessary for this
>>>>> to happen, but if iterators are unacceptably slow in shipping
>>>>> implementations for a year+ I think the odds are good that most
>>>>> shipping software will avoid using them, at which point VM authors
>>>>> will have no reason to optimize for primitives nobody uses. =[
>>>>>
>>>>
>>>> Engines are still ramping up on ES6 features, and most probably haven't
>>>> been able to put much resources into optimisations yet (ES6 is large!). You
>>>> can't compare it to old features that have been tuned for a decade and
>>>> expect equal performance. This situation is unfortunate but unavoidable.
>>>>
>>>> Either way, it doesn't justify cutting corners in the semantics in a
>>>> naive and premature attempt to optimise (which might even harm more
>>>> highl-level optimisations on the long run). Shared mutable result objects
>>>> would be a horrible API with footgun potential, especially when you start
>>>> to build stream abstractions on top. FWIW, this has been discussed at
>>>> length at some of the meetings.
>>>>
>>>> The fixed layout of the iterator object would allow the GC to allocate
>>>>> it cheaply and in the case of values (like ints) it wouldn't need to
>>>>> trace it either - so that helps a lot. But I don't know how realistic
>>>>> those optimizations are in practice.
>>>>>
>>>>
>>>> Not sure what you mean here. Unfortunately, result objects are still
>>>> mutable and extensible, so anything can happen.
>>>>
>>>> /Andreas
>>>>
>>>>
>>>> On 15 February 2015 at 02:36, Andrea Giammarchi
>>>>>  wrote:
>>>>> > +1 and I've raised same concerns 2 years ago [1]
>>>>> >
>>>>> > IIRC the outcome was that VM should be good enough to handle objects
>>>>> with
>>>>> > very short lifecycle, I'm still convinced (behind tests) that
>>>>> generators are
>>>>> > overkill for IoT devices (low clock and way lower RAM).
>>>>> >
>>>>> > Having always same object per iteration makes sense to me at least
>>>>> until
>>>>> > it's done so that could be just a struct-like `{done: false, value:
>>>>> null}`
>>>>> > object and GC will be happier than ever.
>>>>> >
>>>>> > Regards
>>>>> >
>>>>> >
>>>>> > [1]
>>>>> >
>>>>> http://webreflection.blogspot.co.uk/2013/06/on-harmony-javascript-generators.html
>>>>> >
>>&

Re: Performance of iterator .next() as specified

[Andrea Giammarchi]

Agreed, I see the `.next()` issue similar to an `array.length` in a for
loop where the code inside does not mutate the array anyhow. In that case
there's no need to invoke the getter for the length at each iteration, so I
guess one day we might have similar optimizations in place for generators.


'till that day though ... I rather use old school events for bigger IoT
projects, those always played quite nice (and have been sharing the same
event object for years now without a problem)

just my 2 cents too


On Mon, Feb 16, 2015 at 2:40 PM, Bradley Meck 
wrote:

> I think it is important to not attempt to pre-optimize and create partial
> solutions. I is fairly easy for the compiler to understand *when*
> [Symbol.iterator] is invoked and optimize it at that point, same concept as
> on the stack replacement. A better question in my book, is there any engine
> author who is concerned about the difficulty of implementing such an
> optimization.
>
> Having a shared object means much more escape tracking than if the object
> was not shared.
>
> Just my 2 cents.
>
> On Mon, Feb 16, 2015 at 8:32 AM, Andreas Rossberg 
> wrote:
>
>> On 16 February 2015 at 15:21, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> > Shared mutable result objects
>>>
>>> FWIW to me that could be even be a singleton frozen `{done: false,
>>> value: null}` constant during iteration and a new object only once done.
>>>
>>> Would this work or speed-up anything at all?
>>>
>>
>> Frozen value null? I don't understand. You'd get the actual values
>> from... where?
>>
>> /Andreas
>>
>>
>> On Mon, Feb 16, 2015 at 2:04 PM, Andreas Rossberg 
>>> wrote:
>>>
>>>> On 15 February 2015 at 12:07, Katelyn Gadd  wrote:
>>>>
>>>>> I'm certainly in favor of VMs improving to handle that, and adding
>>>>> pressure for it is good. However, optimizing a TypedArray temporary
>>>>> arg to .set() is a much simpler problem than doing the escape analysis
>>>>> necessary to be certain a .next() result doesn't escape from a calling
>>>>> scope and isn't used after a later next() call. Applying pressure will
>>>>> be a good way to make sure VM authors do the work necessary for this
>>>>> to happen, but if iterators are unacceptably slow in shipping
>>>>> implementations for a year+ I think the odds are good that most
>>>>> shipping software will avoid using them, at which point VM authors
>>>>> will have no reason to optimize for primitives nobody uses. =[
>>>>>
>>>>
>>>> Engines are still ramping up on ES6 features, and most probably haven't
>>>> been able to put much resources into optimisations yet (ES6 is large!). You
>>>> can't compare it to old features that have been tuned for a decade and
>>>> expect equal performance. This situation is unfortunate but unavoidable.
>>>>
>>>> Either way, it doesn't justify cutting corners in the semantics in a
>>>> naive and premature attempt to optimise (which might even harm more
>>>> highl-level optimisations on the long run). Shared mutable result objects
>>>> would be a horrible API with footgun potential, especially when you start
>>>> to build stream abstractions on top. FWIW, this has been discussed at
>>>> length at some of the meetings.
>>>>
>>>> The fixed layout of the iterator object would allow the GC to allocate
>>>>> it cheaply and in the case of values (like ints) it wouldn't need to
>>>>> trace it either - so that helps a lot. But I don't know how realistic
>>>>> those optimizations are in practice.
>>>>>
>>>>
>>>> Not sure what you mean here. Unfortunately, result objects are still
>>>> mutable and extensible, so anything can happen.
>>>>
>>>> /Andreas
>>>>
>>>>
>>>> On 15 February 2015 at 02:36, Andrea Giammarchi
>>>>>  wrote:
>>>>> > +1 and I've raised same concerns 2 years ago [1]
>>>>> >
>>>>> > IIRC the outcome was that VM should be good enough to handle objects
>>>>> with
>>>>> > very short lifecycle, I'm still convinced (behind tests) that
>>>>> generators are
>>>>> > overkill for IoT devices (low clock and way lower RAM).
>>>>> >
>>>>> > Having a

Re: Performance of iterator .next() as specified

[Andrea Giammarchi]

> In fact, you can specify a generator function with an infinite loop (like
the infamous while (true) { .. }) that essentially never finishes. While
that's usually madness or a mistake in a normal JS program, with generator
functions it's perfectly sane and sometimes exactly what you want to do!

just probably the most read piece about JS generators 
http://davidwalsh.name/es6-generators

Hence the potential problem caused by `while (!yielded.next().done)`
thousands of objects ... I agree that's not the best way to go with
generators, but I've seen many code-bases based on similar automagic
resolution.

Other example in going async and the `runGenerator` function:
http://davidwalsh.name/async-generators

```js

// run (async) a generator to completion// Note: simplified approach:
no error handling herefunction runGenerator(g) {
var it = g(), ret;

// asynchronously iterate over generator(function iterate(val){
ret = it.next( val );

if (!ret.done) {
// poor man's "is it a promise?" testif
("then" in ret.value) {
// wait on the promiseret.value.then( iterate );
}
// immediate value: just send right back inelse {
// avoid synchronous recursion
setTimeout( function(){
iterate( ret.value );
}, 0 );
}
}
})();}

```

And since one of the purpose/side-effect of generators is to make code look
synchronous, I don't think Kyle went too far or anything, he simply showed
some pattern that I've seen already applied here and there.

So yes, behind libraries or on users hands, the amount of garbage can be
"too damn high"

Best Regards




On Mon, Feb 16, 2015 at 3:45 PM, Andreas Rossberg 
wrote:

> On 16 February 2015 at 15:41, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> Common pattern is to poll.next() a yield until its `done` property is
>> `true` so that a value can be used.
>>
>> This is I believe the common case that will create thousands of objects
>> to be quickly trashed as garbage ... so I was wondering if those are all
>> needed
>>
>
> Er, I don't think this is the common use case at all. You iterate over
> something to process values, otherwise there isn't much point in using
> iterators in the first place.
>
> /Andreas
>
>
>
>> On Mon, Feb 16, 2015 at 2:38 PM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> then frozen `{done: false}` without even the `value` property ... Would
>>> this work or speed-up anything at all?
>>>
>>> On Mon, Feb 16, 2015 at 2:32 PM, Andreas Rossberg 
>>> wrote:
>>>
>>>> On 16 February 2015 at 15:21, Andrea Giammarchi <
>>>> andrea.giammar...@gmail.com> wrote:
>>>>
>>>>> > Shared mutable result objects
>>>>>
>>>>> FWIW to me that could be even be a singleton frozen `{done: false,
>>>>> value: null}` constant during iteration and a new object only once done.
>>>>>
>>>>> Would this work or speed-up anything at all?
>>>>>
>>>>
>>>> Frozen value null? I don't understand. You'd get the actual values
>>>> from... where?
>>>>
>>>> /Andreas
>>>>
>>>>
>>>> On Mon, Feb 16, 2015 at 2:04 PM, Andreas Rossberg 
>>>>> wrote:
>>>>>
>>>>>> On 15 February 2015 at 12:07, Katelyn Gadd  wrote:
>>>>>>
>>>>>>> I'm certainly in favor of VMs improving to handle that, and adding
>>>>>>> pressure for it is good. However, optimizing a TypedArray temporary
>>>>>>> arg to .set() is a much simpler problem than doing the escape
>>>>>>> analysis
>>>>>>> necessary to be certain a .next() result doesn't escape from a
>>>>>>> calling
>>>>>>> scope and isn't used after a later next() call. Applying pressure
>>>>>>> will
>>>>>>> be a good way to make sure VM authors do the work necessary for this
>>>>>>> to happen, but if iterators are unacceptably slow in shipping
>>>>>>> implementations for a year+ I think the odds are good that most
>>>>>>> shipping software will avoid using them, at which point VM authors
>>>>>>> will have no reason to optimize for primitives nobody uses. =[
>>>>>>>
>>>>>>
>>>>&g

Re: Array.prototype change (Was: @@toStringTag spoofing for null and undefined)

[Andrea Giammarchi]

> not evidence of real-world usage that would break popular websites

the Web is (still and thankfully) not about popular websites only.

Using the `Array.prototype` instead of creating instances in the wild has
been seen for long time, same way you don't do `{}.toString.call` but
`Object.prototype.toString.call` instead.

When a method like `concat` has no side effect to the prototype but can be
used as empty starting point for an Array creation, it's perfectly fine to
use it as such utility.

I am not sure that's the only exception though, and I don't have strong
opinion about this specific matter (there must be reasons to change and
software needs updates anyway) but I agree with Kyle that if ES6 claims
backward compatibility, it should stick with it.

This is a breaking change, small or big (famous/populare websites) is sort
of less relevant.

In github, as example, there's some usage already showing up:
https://github.com/search?utf8=%E2%9C%93&q=%22Array.prototype.concat%28%22&type=Code&ref=searchresults

I've also seen many `Array.prototype.concat.call([], ...)` which is
extremely pointless since that is the equivalent of `[].concat(...)` but
from time to time I use similar logic shown in Kyle example with reduce.

Again, I don't remember why these builtins needed such change, but things
like these should be probably announced as "potential breaking" so that
developers can be aware and eventually fix things here or there.

Regards




On Thu, Feb 19, 2015 at 4:38 PM, Domenic Denicola  wrote:

> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> Allen Wirfs-Brock
>
> > This looks like the sort of evidence we asked for.
>
> I don't really think so. This is some tweets and books, not evidence of
> real-world usage that would break popular websites and cause browser game
> theory to kick in. Such evidence is best gathered by browser vendors making
> the change and seeing what it impacts. I believe IE12/Spartan might already
> be doing so---Brian, confirm/deny?
>
> ___
> 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: Array.prototype change (Was: @@toStringTag spoofing for null and undefined)

[Andrea Giammarchi]

I think I do understand ... is this operation valid in ES6 ?

`var oneTwoThree = Array.prototype.concat(1, 2, 3); // [1, 2, 3]`

'cause that was the initial concern, and as far as I understand that will
break.

Or does it?



On Thu, Feb 19, 2015 at 4:59 PM, Domenic Denicola  wrote:

>  Andrea, you seem to not understand what change is being discussed here.
> Nobody is talking about removing or changing the behavior of
> Array.prototype.concat. Please re-read.
>  ------
> From: Andrea Giammarchi 
> Sent: ‎2015-‎02-‎19 11:57
> To: Domenic Denicola 
> Cc: Allen Wirfs-Brock ; es-discuss@mozilla.org list
> 
> Subject: Re: Array.prototype change (Was: @@toStringTag spoofing for null
> and undefined)
>
>  > not evidence of real-world usage that would break popular websites
>
>  the Web is (still and thankfully) not about popular websites only.
>
>  Using the `Array.prototype` instead of creating instances in the wild has
> been seen for long time, same way you don't do `{}.toString.call` but
> `Object.prototype.toString.call` instead.
>
>  When a method like `concat` has no side effect to the prototype but can
> be used as empty starting point for an Array creation, it's perfectly fine
> to use it as such utility.
>
>  I am not sure that's the only exception though, and I don't have strong
> opinion about this specific matter (there must be reasons to change and
> software needs updates anyway) but I agree with Kyle that if ES6 claims
> backward compatibility, it should stick with it.
>
>  This is a breaking change, small or big (famous/populare websites) is
> sort of less relevant.
>
>  In github, as example, there's some usage already showing up:
>
> https://github.com/search?utf8=%E2%9C%93&q=%22Array.prototype.concat%28%22&type=Code&ref=searchresults
>
>  I've also seen many `Array.prototype.concat.call([], ...)` which is
> extremely pointless since that is the equivalent of `[].concat(...)` but
> from time to time I use similar logic shown in Kyle example with reduce.
>
>  Again, I don't remember why these builtins needed such change, but
> things like these should be probably announced as "potential breaking" so
> that developers can be aware and eventually fix things here or there.
>
>  Regards
>
>
>
>
> On Thu, Feb 19, 2015 at 4:38 PM, Domenic Denicola  wrote:
>
>> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
>> Allen Wirfs-Brock
>>
>> > This looks like the sort of evidence we asked for.
>>
>> I don't really think so. This is some tweets and books, not evidence of
>> real-world usage that would break popular websites and cause browser game
>> theory to kick in. Such evidence is best gathered by browser vendors making
>> the change and seeing what it impacts. I believe IE12/Spartan might already
>> be doing so---Brian, confirm/deny?
>>
>> ___
>> 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: Array.prototype change (Was: @@toStringTag spoofing for null and undefined)

[Andrea Giammarchi]

I remember once upon a time double quotes meant explicit intent of exact
match, t least in Google, IIRC, dunno when that good idea got lost.

Yes, it's hard to find for exact matches but if you also check the reduce
example, `Array.prototype` is simply passed around.

Again, I don't know how much would break here, all I know is that it would
be **excellent** to have a list of potentially breaking changes like this
one.
We can debate for days how breaking this is, but as a change ... it breaks,
as Allen confirmed.

Can we have either a list of these changes (I'm sure I've missed many, like
this one, for example) or can we just stick with the "ES6 is backward
compat" umbrella?

Best Regards


On Thu, Feb 19, 2015 at 5:21 PM, Mark S. Miller  wrote:

>
>
> On Thu, Feb 19, 2015 at 8:57 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> > not evidence of real-world usage that would break popular websites
>>
>> the Web is (still and thankfully) not about popular websites only.
>>
>> Using the `Array.prototype` instead of creating instances in the wild has
>> been seen for long time, same way you don't do `{}.toString.call` but
>> `Object.prototype.toString.call` instead.
>>
>> When a method like `concat` has no side effect to the prototype but can
>> be used as empty starting point for an Array creation, it's perfectly fine
>> to use it as such utility.
>>
>> I am not sure that's the only exception though, and I don't have strong
>> opinion about this specific matter (there must be reasons to change and
>> software needs updates anyway) but I agree with Kyle that if ES6 claims
>> backward compatibility, it should stick with it.
>>
>> This is a breaking change, small or big (famous/populare websites) is
>> sort of less relevant.
>>
>> In github, as example, there's some usage already showing up:
>>
>> https://github.com/search?utf8=%E2%9C%93&q=%22Array.prototype.concat%28%22&type=Code&ref=searchresults
>>
>
>
> Take a look again at those results. Although you are indeed searching
> for "Array.prototype.concat(", the first four pages of Github matches I saw
> were for "Array.prototype.concat.apply(", which would still work fine.
>
> Anyone know how to do an exact match search on Github? Since these results
> are sorted by best match, perhaps this indicates that there are no exact
> matches for "Array.prototype.concat(" ?
>
>
>
>
>>
>> I've also seen many `Array.prototype.concat.call([], ...)` which is
>> extremely pointless since that is the equivalent of `[].concat(...)` but
>> from time to time I use similar logic shown in Kyle example with reduce.
>>
>> Again, I don't remember why these builtins needed such change, but things
>> like these should be probably announced as "potential breaking" so that
>> developers can be aware and eventually fix things here or there.
>>
>> Regards
>>
>>
>>
>>
>> On Thu, Feb 19, 2015 at 4:38 PM, Domenic Denicola  wrote:
>>
>>> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
>>> Allen Wirfs-Brock
>>>
>>> > This looks like the sort of evidence we asked for.
>>>
>>> I don't really think so. This is some tweets and books, not evidence of
>>> real-world usage that would break popular websites and cause browser game
>>> theory to kick in. Such evidence is best gathered by browser vendors making
>>> the change and seeing what it impacts.
>>
>>
> Agree with Domenic. The other thing needed quickly is for someone to add
> tests for this to test262, so that there is browser game theory pressure in
> the right direction.
>
>
>
>
>> I believe IE12/Spartan might already be doing so---Brian, confirm/deny?
>>>
>>
> Indeed. If there is already a browser testing the waters, that would be
> exactly the kind of evidence we need.
>
>
> --
> Cheers,
> --MarkM
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.freeze(Object.prototype) VS reality

[Andrea Giammarchi]

Just as workaround, if you really need that much to freeze the
`Object.prototype`, you could:

```js
Object
  .getOwnPropertyNames(Object.prototype)
  .filter((name) => !/^constructor|toString|valueIOf$/.test(name))
  .forEach((name) => Object.defineProperty(
Object.prototype,
name,
{value: Object.prototype[name]}
  ))
;
Object.preventExtensions(Object.prototype);
```

You can eventually fix those 3 properties somehow via accessors.

Not ideal, but it should hopefully make your project work (at least)

Best Regards


On Thu, Feb 19, 2015 at 5:23 PM, David Bruant  wrote:

> Hi,
>
> Half a million times the following meta-exchange happened on es-discuss:
> - if an attacker modifies Object.prototype, then you're doomed in all
> sorts of ways
> - Don't let anyone modify it. Just do Object.freeze(Object.prototype)!
>
> I've done it on client-side projects with reasonable success. I've just
> tried on a Node project and lots of dependencies started throwing errors.
> (I imagine the difference is that in Node, it's easy to create projects
> with a big tree of dependencies which I haven't done too much on the client
> side).
>
> I tracked down a few of these errors and they all seem to relate to the
> override mistake [1].
> * In jsdom [2], trying to add a "constructor" property to an object fails
> because Object.prototype.constructor is configurable: false, writable: false
> * in tough-cookie [3] (which is a dependency of the popular 'request'
> module), trying to set Cookie.prototype.toString fails because
> Object.prototype.toString is configurable: false, writable: false
>
> Arguably, they could use Object.defineProperty, but they won't because
> it's less natural and it'd be absurd to try to fix npm. The
> Cookie.prototype.toString case is interesting. Of all the methods being
> added, only toString causes a problem. Using Object.defineProperty for this
> one would be an awkward inconsistency.
>
>
> So, we're in a state where no module needs to modify Object.prototype, but
> I cannot freeze it because the override mistake makes throw any script that
> tries to set a toString property to an object.
> Because of the override mistake, either I have to let Object.prototype
> mutable (depite no module needing it to be mutable) or freeze it first hand
> and not use popular modules like jsdom or request.
>
> It's obviously possible to replace all built-in props by accessors [4], of
> course, but this is a bit ridiculous.
> Can the override mistake be fixed? I imagine no web compat issues would
> occur since this change is about throwing less errors.
>
> David
>
> [1] http://wiki.ecmascript.org/doku.php?id=strawman:fixing_
> override_mistake
> [2] https://github.com/tmpvar/jsdom/blob/6c5fe5be8cd01e0b4e91fa96d02534
> 1aff1db291/lib/jsdom/utils.js#L65-L95
> [3] https://github.com/goinstant/tough-cookie/blob/
> c66bebadd634f4ff5d8a06519f9e0e4744986ab8/lib/cookie.js#L694
> [4] https://github.com/rwaldron/tc39-notes/blob/
> c61f48cea5f2339a1ec65ca89827c8cff170779b/es6/2012-07/july-
> 25.md#fix-override-mistake-aka-the-can-put-check
> ___
> 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.freeze(Object.prototype) VS reality

[Andrea Giammarchi]

this, and the fact descriptors suffer inheritance which for 3 boolean
properties or a method are absolutely not helpful and make the env doomed
by `Object.prototype.writable = true` shenanigans.

Yes, I'd personally +1 all these fixes that made these ES5 features not the
easiest one to play with

On Thu, Feb 19, 2015 at 5:41 PM, Mark S. Miller  wrote:

> On Thu, Feb 19, 2015 at 9:23 AM, David Bruant  wrote:
>
>> Hi,
>>
>> Half a million times the following meta-exchange happened on es-discuss:
>> - if an attacker modifies Object.prototype, then you're doomed in all
>> sorts of ways
>> - Don't let anyone modify it. Just do Object.freeze(Object.prototype)!
>>
>> I've done it on client-side projects with reasonable success. I've just
>> tried on a Node project and lots of dependencies started throwing errors.
>> (I imagine the difference is that in Node, it's easy to create projects
>> with a big tree of dependencies which I haven't done too much on the client
>> side).
>>
>> I tracked down a few of these errors and they all seem to relate to the
>> override mistake [1].
>> * In jsdom [2], trying to add a "constructor" property to an object fails
>> because Object.prototype.constructor is configurable: false, writable: false
>> * in tough-cookie [3] (which is a dependency of the popular 'request'
>> module), trying to set Cookie.prototype.toString fails because
>> Object.prototype.toString is configurable: false, writable: false
>>
>> Arguably, they could use Object.defineProperty, but they won't because
>> it's less natural and it'd be absurd to try to fix npm. The
>> Cookie.prototype.toString case is interesting. Of all the methods being
>> added, only toString causes a problem. Using Object.defineProperty for this
>> one would be an awkward inconsistency.
>>
>>
>> So, we're in a state where no module needs to modify Object.prototype,
>> but I cannot freeze it because the override mistake makes throw any script
>> that tries to set a toString property to an object.
>> Because of the override mistake, either I have to let Object.prototype
>> mutable (depite no module needing it to be mutable) or freeze it first hand
>> and not use popular modules like jsdom or request.
>>
>> It's obviously possible to replace all built-in props by accessors [4],
>> of course, but this is a bit ridiculous.
>>
>
> It is indeed ridiculous. Not fixing this in the ES5 timeframe was my
> single biggest failure and disappointment as a member of TC39.
>
> For reference, Caja's implementation of the technique described in [4] is
> at
>
>
> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#278
>
> As it states, our term for freezing an object so that it does not provoke
> this problem is "tamper proofing".
>
>
>
>> Can the override mistake be fixed? I imagine no web compat issues would
>> occur since this change is about throwing less errors.
>>
>
> There was a time when some of the browsers did not suffer from the
> override mistake, and in so doing, were technically out of conformance with
> the ES5 spec. During this window, it was clearly still web compatible to
> fix the override mistake. It was during this window that I raised the issue
> and argued that it be fixed. I brought this up in meetings several times
> and never made any progress. Once all browsers suffered equally from the
> override mistake, it was no longer *clearly* web compatible to fix it, so I
> gave up and focussed on other things instead.
>
> However, I agree with your suspicion that it actually would still be web
> compatible to fix this. Unfortunately, the only way to find out at this
> point is for a browser to try deploying without the override mistake. I
> don't have much hope.
>
> Instead, I suggest you promote tamper proofing to those audiences to which
> you currently promote freezing. Though the need for it is indeed
> ridiculous, it actually works rather well. We've been using it successfully
> for many years now.
>
>
>
>
>>
>> David
>>
>> [1] http://wiki.ecmascript.org/doku.php?id=strawman:fixing_
>> override_mistake
>> [2] https://github.com/tmpvar/jsdom/blob/6c5fe5be8cd01e0b4e91fa96d02534
>> 1aff1db291/lib/jsdom/utils.js#L65-L95
>> [3] https://github.com/goinstant/tough-cookie/blob/
>> c66bebadd634f4ff5d8a06519f9e0e4744986ab8/lib/cookie.js#L694
>> [4] https://github.com/rwaldron/tc39-notes/blob/
>> c61f48cea5f2339a1ec65ca89827c8cff170779b/es6/2012-07/july-
>> 25.md#fix-override-mistake-aka-the-can-put-check
>> ___
>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype change (Was: @@toStringTag spoofing for null and undefined)

[Andrea Giammarchi]

Annex E ... I've never reached that part ... Thanks!

On Thu, Feb 19, 2015 at 5:42 PM, Domenic Denicola  wrote:

> From: Andrea Giammarchi [mailto:andrea.giammar...@gmail.com]
>
> > Can we have either a list of these changes (I'm sure I've missed many,
> like this one, for example)
>
>
> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-in-the-6th-edition
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.freeze(Object.prototype) VS reality

[Andrea Giammarchi]

uhm ... have I forgotten a `delete` or should I have set `{value:
Object.prototype[name],
writable: false, configurable: false}` instead ? (enumerable should be
preserved as false too)

Yep, actually you got me there, this is a light side effect since usually
nobody redefines the `Object.prototype`, but good to know, I could have
fallen hard there.

Cheers

On Thu, Feb 19, 2015 at 6:06 PM, Mark S. Miller  wrote:

>
>
> On Thu, Feb 19, 2015 at 9:54 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> Just as workaround, if you really need that much to freeze the
>> `Object.prototype`, you could:
>>
>> ```js
>> Object
>>   .getOwnPropertyNames(Object.prototype)
>>   .filter((name) => !/^constructor|toString|valueIOf$/.test(name))
>>   .forEach((name) => Object.defineProperty(
>> Object.prototype,
>> name,
>> {value: Object.prototype[name]}
>>   ))
>>
>
>
> Your defineProperty call above has no effect. When doing a defineProperty
> on an existing property, recall that omitting attributes means that the
> setting of these attributes should not be changed. Omitted attributes only
> default to false when the property does not already exist.
>
> Interesting that I've seen this bug several times now, by several
> different authors. Apparently, it is an unanticipated footgun in the ES5
> reflection API.
>
>
>
>> ;
>> Object.preventExtensions(Object.prototype);
>> ```
>>
>> You can eventually fix those 3 properties somehow via accessors.
>>
>> Not ideal, but it should hopefully make your project work (at least)
>>
>> Best Regards
>>
>>
>> On Thu, Feb 19, 2015 at 5:23 PM, David Bruant  wrote:
>>
>>> Hi,
>>>
>>> Half a million times the following meta-exchange happened on es-discuss:
>>> - if an attacker modifies Object.prototype, then you're doomed in all
>>> sorts of ways
>>> - Don't let anyone modify it. Just do Object.freeze(Object.prototype)!
>>>
>>> I've done it on client-side projects with reasonable success. I've just
>>> tried on a Node project and lots of dependencies started throwing errors.
>>> (I imagine the difference is that in Node, it's easy to create projects
>>> with a big tree of dependencies which I haven't done too much on the client
>>> side).
>>>
>>> I tracked down a few of these errors and they all seem to relate to the
>>> override mistake [1].
>>> * In jsdom [2], trying to add a "constructor" property to an object
>>> fails because Object.prototype.constructor is configurable: false,
>>> writable: false
>>> * in tough-cookie [3] (which is a dependency of the popular 'request'
>>> module), trying to set Cookie.prototype.toString fails because
>>> Object.prototype.toString is configurable: false, writable: false
>>>
>>> Arguably, they could use Object.defineProperty, but they won't because
>>> it's less natural and it'd be absurd to try to fix npm. The
>>> Cookie.prototype.toString case is interesting. Of all the methods being
>>> added, only toString causes a problem. Using Object.defineProperty for this
>>> one would be an awkward inconsistency.
>>>
>>>
>>> So, we're in a state where no module needs to modify Object.prototype,
>>> but I cannot freeze it because the override mistake makes throw any script
>>> that tries to set a toString property to an object.
>>> Because of the override mistake, either I have to let Object.prototype
>>> mutable (depite no module needing it to be mutable) or freeze it first hand
>>> and not use popular modules like jsdom or request.
>>>
>>> It's obviously possible to replace all built-in props by accessors [4],
>>> of course, but this is a bit ridiculous.
>>> Can the override mistake be fixed? I imagine no web compat issues would
>>> occur since this change is about throwing less errors.
>>>
>>> David
>>>
>>> [1] http://wiki.ecmascript.org/doku.php?id=strawman:fixing_
>>> override_mistake
>>> [2] https://github.com/tmpvar/jsdom/blob/6c5fe5be8cd01e0b4e91fa96d02534
>>> 1aff1db291/lib/jsdom/utils.js#L65-L95
>>> [3] https://github.com/goinstant/tough-cookie/blob/
>>> c66bebadd634f4ff5d8a06519f9e0e4744986ab8/lib/cookie.js#L694
>>> [4] https://github.com/rwaldron/tc39-notes/blob/
>>> c61f48cea5f2339a1ec65ca89827c8cff170779b/es6/2012-07/july-
>>> 25.md#fix-override-mistake-aka-the-can-put-check
>>> ___
>>> 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
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.freeze(Object.prototype) VS reality

[Andrea Giammarchi]

Yeah, beside the fact whenever you freeze something, and you create a
module, or a library, or whatever, you don't know what you are freezing up.

Since priority is arbitrary, if script A sets stuff before script B then
you are done.

Also, I use Object.prototype without causing any sort of problems/error
since years now, nobody complained, but an Object.freeze upfront would
screw the library anyway.

Trust what you load in and avoid XSS from users as much as you can  you
have your problem fixed for most of the cases (and the current state of JS)

Best Regards



On Thu, Feb 19, 2015 at 6:50 PM, Andri Möll  wrote:

> this, and the fact descriptors suffer inheritance which for 3 boolean
> properties or a method are absolutely not helpful and make the env doomed
> by `Object.prototype.writable = true` shenanigans.
>
>
> Umm, those solutions are in opposition. If you seal-freeze-scotch-tape
> Object.prototype up, no-one's going to add `get`s, `set`s and `writable`s
> to it. Taking inheritance into account in defineProperty won’t then be a
> problem.
>
> A.
>
> On Feb 19, 2015, at 19:58, Andrea Giammarchi 
> wrote:
>
> this, and the fact descriptors suffer inheritance which for 3 boolean
> properties or a method are absolutely not helpful and make the env doomed
> by `Object.prototype.writable = true` shenanigans.
>
> Yes, I'd personally +1 all these fixes that made these ES5 features not
> the easiest one to play with
>
> On Thu, Feb 19, 2015 at 5:41 PM, Mark S. Miller 
> wrote:
>
>> On Thu, Feb 19, 2015 at 9:23 AM, David Bruant  wrote:
>>
>>> Hi,
>>>
>>> Half a million times the following meta-exchange happened on es-discuss:
>>> - if an attacker modifies Object.prototype, then you're doomed in all
>>> sorts of ways
>>> - Don't let anyone modify it. Just do Object.freeze(Object.prototype)!
>>>
>>> I've done it on client-side projects with reasonable success. I've just
>>> tried on a Node project and lots of dependencies started throwing errors.
>>> (I imagine the difference is that in Node, it's easy to create projects
>>> with a big tree of dependencies which I haven't done too much on the client
>>> side).
>>>
>>> I tracked down a few of these errors and they all seem to relate to the
>>> override mistake [1].
>>> * In jsdom [2], trying to add a "constructor" property to an object
>>> fails because Object.prototype.constructor is configurable: false,
>>> writable: false
>>> * in tough-cookie [3] (which is a dependency of the popular 'request'
>>> module), trying to set Cookie.prototype.toString fails because
>>> Object.prototype.toString is configurable: false, writable: false
>>>
>>> Arguably, they could use Object.defineProperty, but they won't because
>>> it's less natural and it'd be absurd to try to fix npm. The
>>> Cookie.prototype.toString case is interesting. Of all the methods being
>>> added, only toString causes a problem. Using Object.defineProperty for this
>>> one would be an awkward inconsistency.
>>>
>>>
>>> So, we're in a state where no module needs to modify Object.prototype,
>>> but I cannot freeze it because the override mistake makes throw any script
>>> that tries to set a toString property to an object.
>>> Because of the override mistake, either I have to let Object.prototype
>>> mutable (depite no module needing it to be mutable) or freeze it first hand
>>> and not use popular modules like jsdom or request.
>>>
>>> It's obviously possible to replace all built-in props by accessors [4],
>>> of course, but this is a bit ridiculous.
>>>
>>
>> It is indeed ridiculous. Not fixing this in the ES5 timeframe was my
>> single biggest failure and disappointment as a member of TC39.
>>
>> For reference, Caja's implementation of the technique described in [4] is
>> at
>>
>>
>> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#278
>>
>> As it states, our term for freezing an object so that it does not provoke
>> this problem is "tamper proofing".
>>
>>
>>
>>> Can the override mistake be fixed? I imagine no web compat issues would
>>> occur since this change is about throwing less errors.
>>>
>>
>> There was a time when some of the browsers did not suffer from the
>> override mistake, and in so doing, were technically out of conformance with
>> the ES5 spec. During this wind

Re: Array.prototype change (Was: @@toStringTag spoofing for null and undefined)

[Andrea Giammarchi]

if we'd like to have Array.empty, Function.empty, String.empty and friends,
what's wrong with having these as we always had already: as prototypes?

I see just moving and duplicating gotchas, instead of keeping in a well
known behavior.

This exotic "problem" ... I never really understood it, I blindly trusted
it was needed to avoid that kind of invisible Empty constructor
Function.prototype inherits from ... which is the Empty we all look for too.

Oh well, chicken/eggs inheritance is hard I guess :D

Just kidding, if not for good reasons, throw away 60% of Annex E ( also the
Array thingy is duplicated in there, it's at the bottom and before too in
the HTML version ... just saying )




On Thu, Feb 19, 2015 at 7:33 PM, Kyle Simpson  wrote:

> > are there any other builtins that anybody (Kyle, or otherwise) sees as
> problematic to continue with the breaking change
>
> As that book chapter mentions, the only other one I've ever used is
> RegExp.prototype (being the default empty match /(?:)/ regular expression).
> I have used that only once in my recollection, though I've certainly taught
> it so I don't know if others ever did. I would *like* it to keep working,
> but it's not a sword I'd die on. AWB has suggested on twitter a patch to
> test() and exec() that could hack around that case while letting the ES6
> change go through.
>
> > Kyle, if there was Array.empty and Function.empty, which would both be
> polyfillable, would you find those sufficient replacements for your current
> usages of Function.prototype and Array.prototype?
>
> Yes, a long time back I proposed (not on here, but informally) that there
> should be just such a thing Function.empty, but basically just settled back
> into using `Function.prototype` since it was already there (and I didn't
> conceive of it ever changing).
>
> The points in favor of either the prototype exotic or an "empty" stand-in
> are: 1) convenience  2) possible performance aide to engines.
>
> > can we provide for this use case
>
> I certainly wasn't coming to this list to propose new features for ES6, as
> late as it is. I only just late last nite found out about this change, and
> was just hoping it wasn't too late to abort the change. But if the
> fix/compromise is empty stand-ins that give a polyfill path to migration,
> I'd be OK with that.
> ___
> 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: Array.prototype change (Was: @@toStringTag spoofing for null and undefined)

[Andrea Giammarchi]

yep, not only you can, but also consider if that was frozen, half of ES5
wouldn't have existed.

You want to exted it? Thanks to ES5 just go for it! You want to be
obtrusive or that secure? Freeze it.
Does this affect the ability to use Array.prototype as empty array? Not at
all, it does not change a single bit of empty purpose.

On Thu, Feb 19, 2015 at 8:18 PM, Mark Miller  wrote:

> On Thu, Feb 19, 2015 at 12:14 PM, Axel Rauschmayer 
> wrote:
>
>> However, you can’t freeze `Array.prototype`
>>
>> We do.
>
>
> --
>   Cheers,
>   --MarkM
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype change (Was: @@toStringTag spoofing for null and undefined)

[Andrea Giammarchi]

P.S. yes, the semantic already frozen purpose of an empty property though,
I agree that'd be cool

On Thu, Feb 19, 2015 at 8:21 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> yep, not only you can, but also consider if that was frozen, half of ES5
> wouldn't have existed.
>
> You want to exted it? Thanks to ES5 just go for it! You want to be
> obtrusive or that secure? Freeze it.
> Does this affect the ability to use Array.prototype as empty array? Not at
> all, it does not change a single bit of empty purpose.
>
> On Thu, Feb 19, 2015 at 8:18 PM, Mark Miller  wrote:
>
>> On Thu, Feb 19, 2015 at 12:14 PM, Axel Rauschmayer 
>> wrote:
>>
>>> However, you can’t freeze `Array.prototype`
>>>
>>> We do.
>>
>>
>> --
>>   Cheers,
>>   --MarkM
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Class syntax enhancements

[Andrea Giammarchi]

FWIW when I mixin objects (that are considered traits) into classes [1],
methods and accessors are assigned as other classes methods/accessors would
(non enumerable)

It feels right and work as expected, so your example would simply be

```js

class Foo {
  with: [{
bar, /* Existing method */
additionalMethod() { ... }, /* New method */
  }],
  ...
}

```

all at definition time which is IMO easier to read and follow too.

All other utilities to eventually extend in a different ways could be
always used, of course, but I think there should be some
imported-into-class behavior provided by mixins or with or traits or
however that will be called when it'll be the right time.

Just my 2 cents, Best Regards

[1] https://github.com/WebReflection/es-class/blob/master/FEATURES.md#with
( see Aplication class )

On Fri, Feb 20, 2015 at 9:51 AM, Leon Arnott  wrote:

> Ah, right, my apologies for misreading.
>
> So... I think this scenario would be better served if ES7 had shorthands
> for non-(enumerability|writability|configurability) added to the object
> literal syntax, as some in the past have postulated - and a method for
> copying non-enumerable (and also symbol-keyed) properties was available.
>
> ```
> class Foo { ... }
>
> Object.copyOwnProperties(Foo.prototype, {
>   noenum bar, /* Assigns 'bar' to the object, making it non-enumerable and
> non-writable */
>   noenum additionalMethod() { ... },
>   noenum *[Symbol.iterator]() { ... },
> });
> ```
>
> Object.assign vs Object.copyOwnProperties may seem awkward, but it's
> arguably comparable to the Object.keys/Object.getOwnPropertyNames dichotomy
> - one for the common case, one for the thorough case. (I'm aware that
> Object.getOwnPropertyNames is deprecated in favour of Reflect.ownKeys,
> though.)
>
> In cases where all the methods are new, this could be "simplified" to:
>
> ```
> Object.copyOwnProperties(Foo.prototype, class {
>   baz() { ... }
>   *[Symbol.iterator]() { ... }
> }.prototype);
> ```
>
> Of course, while writing all this I just thought of yet another problem:
> there's no way to copy accessors using this hypothetical
> Object.copyOwnProperties.
>
> Maybe there should also be a specially tuned method on Function:
>
> ```
> Function.assign(Foo, class {
>   qux() {...}
>   *[Symbol.iterator] {...}
>   get flib() {...}
>   static flab() {...}
> });
> ```
>
> And let copyOwnProperties be used for assigning existing methods.
>
> Classes are kind of an awkward data structure, I must say. :|
>
>
> ___
> 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: Class syntax enhancements

[Andrea Giammarchi]

They want magic most of time anyway :-)

I wasn't saying enumerable and others are keywords aren't a bad idea, I'm
say when you import to class you would probably expect non enumerable
anyway, and too verbose class declarations aren't that good-looking.

Hope you got my point.

Regards

On Fri, Feb 20, 2015 at 10:28 AM, Glen Huang  wrote:

> Thanks for the examples. But I wonder why beat around the bush and not let
> developers express exactly what they want?
>
> > On Feb 20, 2015, at 5:51 PM, Leon Arnott  wrote:
> >
> > Ah, right, my apologies for misreading.
> >
> > So... I think this scenario would be better served if ES7 had shorthands
> for non-(enumerability|writability|configurability) added to the object
> literal syntax, as some in the past have postulated - and a method for
> copying non-enumerable (and also symbol-keyed) properties was available.
> >
> > ```
> > class Foo { ... }
> >
> > Object.copyOwnProperties(Foo.prototype, {
> >   noenum bar, /* Assigns 'bar' to the object, making it non-enumerable
> and non-writable */
> >   noenum additionalMethod() { ... },
> >   noenum *[Symbol.iterator]() { ... },
> > });
> > ```
> >
> > Object.assign vs Object.copyOwnProperties may seem awkward, but it's
> arguably comparable to the Object.keys/Object.getOwnPropertyNames dichotomy
> - one for the common case, one for the thorough case. (I'm aware that
> Object.getOwnPropertyNames is deprecated in favour of Reflect.ownKeys,
> though.)
> >
> > In cases where all the methods are new, this could be "simplified" to:
> >
> > ```
> > Object.copyOwnProperties(Foo.prototype, class {
> >   baz() { ... }
> >   *[Symbol.iterator]() { ... }
> > }.prototype);
> > ```
> >
> > Of course, while writing all this I just thought of yet another problem:
> there's no way to copy accessors using this hypothetical
> Object.copyOwnProperties.
> >
> > Maybe there should also be a specially tuned method on Function:
> >
> > ```
> > Function.assign(Foo, class {
> >   qux() {...}
> >   *[Symbol.iterator] {...}
> >   get flib() {...}
> >   static flab() {...}
> > });
> > ```
> >
> > And let copyOwnProperties be used for assigning existing methods.
> >
> > Classes are kind of an awkward data structure, I must say. :|
> >
>
> ___
> 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: *.empty Idea

[Andrea Giammarchi]

quick one to whoever will write the proposal: please bear in mind the empty
function **must** have a frozen prototype too

Regards

On Sun, Feb 22, 2015 at 11:18 PM, Jordan Harband  wrote:

> I'd love to bring a proposal to the committee for this since it seems like
> there's interest.
>
> I suspect that even though some of the "empties" seem useless to some,
> somebody somewhere will find a use case, and consistency is useful (that
> everything that could have a concept of "empty" would have a .empty)
>
> Errata:
>  - I don't believe `GeneratorFunction` is a global, so we wouldn't need to
> specify one of those
>  - I wonder if `Promise.empty` as `new Promise()`, ie, a forever pending
> promise, would make sense?
>  - or `Date.empty` as `new Date(0)`?
>  - We'd definitely want `Map.empty` and `Set.empty` assuming
> `Object.freeze` actually froze them
>  - We'd probably want
> `Object.freeze(Object.seal(Object.preventExtensions(empty)))`, to be extra
> restrictive.
>
> Does anyone see any problems or have any objections, beyond "I don't think
> there's a use case"?
>
> On Sun, Feb 22, 2015 at 2:58 PM, Isiah Meadows 
> wrote:
>
>> I really liked Jordan Harband's suggestion
>> 
>>  of
>> adding Array.empty, Function.empty, etc. to ES7. It is relatively easy to
>> polyfill as well.
>>
>> ```js
>> [Array,
>>  ArrayBuffer,
>>  Int8Array,
>>  Int16Array,
>>  Int32Array,
>>  Uint8Array,
>>  Uint8ClampedArray,
>>  Uint16Array,
>>  Uint32Array,
>>  Float32Array,
>>  Float64Array]
>> .map(T => [T, new T(0)])
>> .concat([
>>   [Object, {}],
>>   [String, ''],
>>   [RegExp, /(?:)/],
>>   [Function, function () {}],
>>   [GeneratorFunction, function* () {}]
>> ])
>> .forEach(([root, empty]) =>
>>   Object.defineProperty(root, 'empty', {
>> value: Object.freeze(empty),
>> configurable: true,
>> enumerable: false,
>> writable: false
>>   }));
>> ```
>>
>> The code effectively explains what I think would make suitable
>> replacements for each. I don't see the use cases for some of these, though,
>> such as `String.empty` or `RegExp.empty`.
>>
>> --
>> Isiah Meadows
>>
>> ___
>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Function "name" property

[Andrea Giammarchi]

I miss you `arguments.callee`, specially in this "fat arrows era" where
most of the time developers don't even care about removing listeners.

Apologies for the laud thought and Best Regards

On Thu, Feb 26, 2015 at 4:32 PM, Allen Wirfs-Brock 
wrote:

>
> On Feb 26, 2015, at 4:10 AM, Leon Arnott wrote:
>
> The twitter thread starts here:
> https://twitter.com/getify/status/570614952605560838 and basically boils
> down to the observation that this:
> ```
> ({ f() { return f; }}.f()) /* ReferenceError (probably) */
> ```
> is not semantically identical to this:
> ```
> ({ f: function f() { return f; } }.f()) /* function f() */
> ```
> That is, concise methods cannot seamlessly recursively call or reference
> themselves. (Personally, I feel like concise methods *should* be a binding
> within themselves in a manner identical to named function expressions, but
> if this has been discussed before and discarded then I understand.)
>
> You may notice that both of the methods above have the same name, "f", in
> spite of one lacking the lexical binding. Formerly, named functions always
> (barring internal var statements etc.) had lexical bindings to themselves,
> and the whole ES6 function name inference dealie breaks this correlation. I
> don't think this is really an important issue, though - assuming that a
> `.name` property equated to a binding was not a safe assumption (especially
> since IE never implemented `.name` but did support the binding).
>
>
> Note that property names are restricted to being valid identifiers.  Note
> of the following concise methods could possibly use their property name as
> a lexical binding:
>
> let o = {
>   42() {},
>   " this is not an identifier"() {},
>   ""() {},
>   if() {},
>   [Symbol.iterate]() {}
> };
>
> We may have a universal way for functions to self reference themselves i
> post ES6.
>
> 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: Function "name" property

[Andrea Giammarchi]

`callee` could be spec'd similar to `super` and transpiled or resolved
statically instead of dynamically, but `callee.caller` or in general the
function `caller` raised many security concerns, giving you the ability to
reach objects you probably shouldn't have.

These two were different beasts, but `callee` for numerous reasons, and
specially for anonymous and non referenced Object methods syntax, is really
leaving a hole in the language, IMO

Best Regards

On Thu, Feb 26, 2015 at 5:41 PM, Felipe Nascimento de Moura <
felipenmo...@gmail.com> wrote:

> that's true!
> I miss that too!
> We are working on a framework for the company here, and sometimes, getting
> the callee would be really useful, and we simply can't!!!
> Removing the arguments.caller/calee could make more sense if, like other
> features, had been replaced by another syntax.
>
> What was the main reason why caller/calee were removed?
>
> Cheers.
>
>
> On Thu, Feb 26, 2015 at 2:09 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> I miss you `arguments.callee`, specially in this "fat arrows era" where
>> most of the time developers don't even care about removing listeners.
>>
>> Apologies for the laud thought and Best Regards
>>
>> On Thu, Feb 26, 2015 at 4:32 PM, Allen Wirfs-Brock > > wrote:
>>
>>>
>>> On Feb 26, 2015, at 4:10 AM, Leon Arnott wrote:
>>>
>>> The twitter thread starts here:
>>> https://twitter.com/getify/status/570614952605560838 and basically
>>> boils down to the observation that this:
>>> ```
>>> ({ f() { return f; }}.f()) /* ReferenceError (probably) */
>>> ```
>>> is not semantically identical to this:
>>> ```
>>> ({ f: function f() { return f; } }.f()) /* function f() */
>>> ```
>>> That is, concise methods cannot seamlessly recursively call or reference
>>> themselves. (Personally, I feel like concise methods *should* be a binding
>>> within themselves in a manner identical to named function expressions, but
>>> if this has been discussed before and discarded then I understand.)
>>>
>>> You may notice that both of the methods above have the same name, "f",
>>> in spite of one lacking the lexical binding. Formerly, named functions
>>> always (barring internal var statements etc.) had lexical bindings to
>>> themselves, and the whole ES6 function name inference dealie breaks this
>>> correlation. I don't think this is really an important issue, though -
>>> assuming that a `.name` property equated to a binding was not a safe
>>> assumption (especially since IE never implemented `.name` but did support
>>> the binding).
>>>
>>>
>>> Note that property names are restricted to being valid identifiers.
>>> Note of the following concise methods could possibly use their property
>>> name as a lexical binding:
>>>
>>> let o = {
>>>   42() {},
>>>   " this is not an identifier"() {},
>>>   ""() {},
>>>   if() {},
>>>   [Symbol.iterate]() {}
>>> };
>>>
>>> We may have a universal way for functions to self reference themselves i
>>> post ES6.
>>>
>>> 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
>>
>>
>
>
> --
> *Felipe N. Moura*
> Senior Web Developer
>
> Website:  http://felipenmoura.org
> Twitter:@felipenmoura <http://twitter.com/felipenmoura>
> LinkedIn: http://goo.gl/qGmq
>
> Meet some of my projects:
> BrazilJS Conference <http://braziljs.com.br/>  |  BrazilJS Foundation
> <http://braziljs.org>  |  Power Polygon
> <http://github.com/braziljs/power-polygon>  |  TheWebMind
> <http://thewebmind.org/>  |  PHPDevBar
> <https://addons.mozilla.org/pt-BR/firefox/addon/php-developer-toolbar/>
> -
> LinuxUser #508332
> *Changing  the  world*  is the least I expect from  myself!
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Function "name" property

[Andrea Giammarchi]

FWIW, that looks great to me Allen, thanks for writing that down!


I specially like that it's going to take just about 22 years before
`arguments` will be usable as Array ... eh eh eh, about the time :D

Best Regards

On Thu, Feb 26, 2015 at 10:17 PM, Allen Wirfs-Brock 
wrote:

> I send a new topic message about the following, but for some reason it
> seems slow getting to es-discuss. So, I'm trying it via a replay:
>
> Here is a new proposal for some additional meta properties that should be
> considered for ES7
> https://github.com/allenwb/ESideas/blob/master/ES7MetaProps.md
>
>
>
>
> On Feb 26, 2015, at 12:19 PM, Mark S. Miller wrote:
>
> On Thu, Feb 26, 2015 at 10:52 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> `callee` could be spec'd similar to `super` and transpiled or resolved
>> statically instead of dynamically, but `callee.caller` or in general the
>> function `caller` raised many security concerns, giving you the ability to
>> reach objects you probably shouldn't have.
>>
>> These two were different beasts, but `callee` for numerous reasons, and
>> specially for anonymous and non referenced Object methods syntax, is really
>> leaving a hole in the language, IMO
>>
>
>
> To respond to this, I searched in vain for the following message on
> es-discuss, only to find it in a private thread. This message helped
> contribute towards the syntactic direction we finally took, where allowable
> new meta-accesses are introduces by ., but only for
> keywords that are not valid expressions by themselves. ES6 contains the
> first example of this in "new.target". Many thanks to David Herman for this
> generalization -- I didn't see it at all.
>
> Note that most of the meta.* proposals I list below I am not advocating --
> indeed I think most are probably bad ideas. I include them only as examples
> of what lexical context meta accesses could be soundly added to the
> language as special forms.
>
> For the record:
>
>
> -- Forwarded message --
> From: Mark S. Miller 
> Date: Fri, Jan 2, 2015 at 5:10 PM
> Subject: Re: Subclassing Builtins
>
>
> [...] close but not quite. E has a lexical reflective access special form
> that gives quite a lot of access -- the "meta" keyword. The important
> features that make it non-objectionable:
>
> a) Its usage patterns is to extract from it the more specific reflective
> access needed for each use.
> b) Its API is designed to encourage such authority division on use.
> c) It is understood and documented from the beginning as giving broad
> access, so hopefully no one will mistake it for providing less access than
> it does.
>
> So, hypothetically, if, say, we introduced "meta" as such a special form
> to JS, then
>
> "meta.arguments" could provide arguments.
> "meta.originalContructor" could provide the original constructor.
> "meta.callee" could provide access to the function it appears in.
> "meta.source" could provide access to the source code of the function it
> appears in.
> "meta.strictness" could be a boolean indicating the strictness of the code
> it appears in.
> "meta.environment" could provide a Map from variable name to value
> reflecting the lexical scope at the place it appears.
>
> More dangerously but still plausibly
> "meta" could provide an object with the above fields. The reason it is
> more dangerous is that passing "meta" might give access to a field added in
> a later spec. The reason it is still plausible is that passing "meta"
> itself, unlike passing "arguments" or "meta.arguments", would be understood
> as passing broad access.
>
> However,
> "meta.caller", as something that provide[s] access to the current
> activation's caller, must still be forbidden.
>
>
> --
> Cheers,
> --MarkM
>  ___
> 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: Proposal: Additional Meta Properties for ES7

[Andrea Giammarchi]

I personally wouldn't mind `self` but it has been historically used as
context or global reference, while callee ... you don't probably need to
explain what's that about.

On the other hand, from `arguments` object, `callee`was more semantic but
it feels not th ebest choice from `function` indeed.

Decisions ... decisions ...

On Thu, Feb 26, 2015 at 11:27 PM, Claude Pache 
wrote:

> Alternative name for `function.callee`:  I find that `function.self`
> sounds better in case of recursive call (and probably in other cases as
> well).
>
> —Claude
>
> Le 26 févr. 2015 à 23:47, Allen Wirfs-Brock  a
> écrit :
>
> Here is a new proposal for some additional meta properties that should be
> considered for ES7
> https://github.com/allenwb/ESideas/blob/master/ES7MetaProps.md
>
> I've added this to the agenda for next months TC39 meeting but pre-meeting
> discussion is always welcomed right here.
>
> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Additional Meta Properties for ES7

[Andrea Giammarchi]

agreed ... between `self` and `callee` probably `self` is better. Anyone
with a different/new idea?

On Thu, Feb 26, 2015 at 11:50 PM, Tab Atkins Jr. 
wrote:

> On Thu, Feb 26, 2015 at 3:27 PM, Claude Pache 
> wrote:
> > Alternative name for `function.callee`:  I find that `function.self`
> sounds
> > better in case of recursive call (and probably in other cases as well).
>
> Agreed that "callee", while technically accurate, is a clumsy word and
> something like "self" sounds better.  "function.self", in particular,
> seems to communicate the right semantic, and implies that you're
> receiving a function .
>
> It doesn't feel... apt, I think, to bring the caller/callee
> relationship to mind when you're not trying to deal with that
> relationship; all you're trying to do is recurse on yourself, in the
> case where you don't have a name to refer to yourself with.  The fact
> that you're running because someone else called you is irrelevant to
> this dynamic.
>
> ~TJ
> ___
> 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: Proposal: Additional Meta Properties for ES7

[Andrea Giammarchi]

had same thought ... that wouldn't need much explanation neither. +1 here

On Thu, Feb 26, 2015 at 11:59 PM, Domenic Denicola  wrote:

>  function.current?
>  --
> From: Andrea Giammarchi 
> Sent: ‎2015-‎02-‎26 18:56
> To: Tab Atkins Jr. 
> Cc: es-discuss 
> Subject: Re: Proposal: Additional Meta Properties for ES7
>
>  agreed ... between `self` and `callee` probably `self` is better. Anyone
> with a different/new idea?
>
> On Thu, Feb 26, 2015 at 11:50 PM, Tab Atkins Jr. 
> wrote:
>
>> On Thu, Feb 26, 2015 at 3:27 PM, Claude Pache 
>> wrote:
>> > Alternative name for `function.callee`:  I find that `function.self`
>> sounds
>> > better in case of recursive call (and probably in other cases as well).
>>
>> Agreed that "callee", while technically accurate, is a clumsy word and
>> something like "self" sounds better.  "function.self", in particular,
>> seems to communicate the right semantic, and implies that you're
>> receiving a function .
>>
>> It doesn't feel... apt, I think, to bring the caller/callee
>> relationship to mind when you're not trying to deal with that
>> relationship; all you're trying to do is recurse on yourself, in the
>> case where you don't have a name to refer to yourself with.  The fact
>> that you're running because someone else called you is irrelevant to
>> this dynamic.
>>
>> ~TJ
>>  ___
>> 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: Proposal: Additional Meta Properties for ES7

[Andrea Giammarchi]

another basic example with listeners

```
window.addEventListener('load', (e) => {
  // how am I going to remove this listener?
  console.log('everything loaded');
});
```

Specially on UI world, many libraries do attach tons of things at runtime,
within methods, and have no way to remove them if not believing the DOM
will take care of everything.

Timers are also less powerful

```js

setTimeout(function later() {
  if (condition) {
moveOn();
  } else {
setTimeout(later, 100);
  }
}, 100);

```

Recursions as Allen wrote already are another example too.

Regards





On Fri, Feb 27, 2015 at 12:42 AM, Garrett Smith 
wrote:

> Can you show an example of how callee is used with a fat arrow function?
>
> (()=>{alert(callee);})()
>
> Thanks.
>
> On 2/26/15, Allen Wirfs-Brock  wrote:
> > Here is a new proposal for some additional meta properties that should be
> > considered for ES7
> > https://github.com/allenwb/ESideas/blob/master/ES7MetaProps.md
> >
> > I've added this to the agenda for next months TC39 meeting but
> pre-meeting
> > discussion is always welcomed right here.
> >
> > Allen
> >
> >
>
>
> --
> Garrett
> @xkit
> ChordCycles.com
> garretts.github.io
> ___
> 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: Cancelable promises

[Andrea Giammarchi]

AFAIK bluebird did:
https://github.com/petkaantonov/bluebird/blob/master/API.md#cancelerror-reason---promise

But I agree once you've made Promises more complex than events ( xhr in
this case ) nobody wins :-/

Although, specially for fetch or anything network related, there **must**
be a way to bloody cancel that!

right?


On Fri, Feb 27, 2015 at 7:31 AM, Kevin Smith  wrote:

> The discussion on that github issue surrounding promise subclassing makes
> my head spin, especially when it comes to working out how cancelation is
> supposed to flow through a graph of promise dependencies.  We should be
> wary of adding complexity to the core.
>
> The simple way to view the situation is to say that promises are simply
> transparent containers for asynchronous values. Control capabilities should
> therefore be represented by a separate abstraction. This will help keep
> complexity at the edges.
>
> Has any library experimented with the cancelation token approach yet?
> On Feb 27, 2015 1:46 AM, "Anne van Kesteren"  wrote:
>
>> As a heads up, there's some debate around the fetch() API how exactly
>> request termination should work and how that affects promises:
>>
>>   https://github.com/slightlyoff/ServiceWorker/issues/625
>>
>> The WebRTC WG has also been discussing canceling in the context of
>> terminating a request for permission from the user. I think they
>> decided to postpone for now until there's a bit more progress on what
>> cancelable promises means, but I would not expect everyone to wait
>> forever.
>>
>>
>> --
>> https://annevankesteren.nl/
>> ___
>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.assign and inherited properties

[Andrea Giammarchi]

You are talking about "flatting" all properties, which is an undesired
overhead.

```js

var b = Object.create(
  Object.getPrototypeOf(a)
);

Object.assign(b, a);

```

But what's bugging me every time more, is that somebody had a very bad idea
to spread `Object.assign` as something good for inheritance or object
cloning.

Where does this come from? `Object.assign` retrieves properties and ignore
getters and setters, is the last tool you want to use as substitution
principle because it breaks.

`Object.assign` is good only to define enumerable, writable, and
configurable properties, like configuration or setup objects.

Are you dealing with prototypes and `Object.assign` ? You gonna have way
more problems than a missed flattered structure.

Can you explain what is your goal ? Wouldn't this work?

```js

var a = {}; // or anything else

var b = Object.create(
  Object.getPrototypeOf(a)
);

Object.getOwnPropertyNames(a).forEach(function (k) {
  Object.defineProperty(b, k, Object.getOwnPropertyDescriptor(a, k));
});

```


Best Regards



On Fri, Feb 27, 2015 at 11:52 AM, Andri Möll  wrote:

> Hello,
>
> Why does Object.assign ignore inherited enumerable properties?
> What is the problem to which ignoring inherited properties is the solution
> to?
>
> All I can see is that it prevents a useful use of inheritance. The Liskov
> substitution principle
>  was
> mentioned 27 years ago in ’87. Why is Object.assign breaking it?
>
> - Everyone who’s messing with Object.prototype has to do it an
> non-enumerable style anyway.
> - Most uses of Object.assign will likely be for objects with a finite
> number of keys. Those form specific and implicit types from which people
> are likely to read with the dot-operator. That takes inheritance into
> account anyway.
>
> I don’t get the agenda to mess with object inheritance. If one wants
> methods to only be in the parent and data on the child (so Object.assign
> would only copy data), use a classical language. In a delegation-prototypal
> language one should be able to inherit freely because of LSP
> .
>
> Andri
>
> ___
> 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.assign and inherited properties

[Andrea Giammarchi]

noone? JSLint doesn't even let you write a for/in loop if you don't have
`obj.hasOwnProperty(key)` in it, and usually nobody wants inherited
properties (included methods from old classes/ahem prototypes) reassigned
everywhere.

If you deal with data objects and dictionaries yuo'll always have a flat
structure, right? If you don't care about properties descriptors (getters
and setters) you can always use a for/in

```
function flatEnumerables(a) {
  for (var c, k, i = 1; i < arguments.length; i++) {
for (k in (c = arguments[i])) a[k] = c[k];
  }
  return a;
}
```
This would do what you are looking for (which is the first time I
personally read/hear about somebody wanting `Object.assign` to behave like
a for/in)

Would that work?

Best Regards



On Fri, Feb 27, 2015 at 12:56 PM, Andri Möll  wrote:

> You are talking about "flatting" all properties, which is an undesired
> overhead.
>
>
> Umm, Object.assign is as it is because of performance? I don’t think it is
> nor is that a good reason. Every property access in JavaScript takes
> inheritance into account and there are thousands more than a Object.assign
> call here and there.
>
> But what's bugging me every time more, is that somebody had a very bad
> idea to spread `Object.assign` as something good for inheritance or object
> cloning.
>
> Where does this come from? `Object.assign` retrieves properties and ignore
> getters and setters, is the last tool you want to use as substitution
> principle because it breaks.
>
>
> Ignores getters? You mean merely reads them? That’s not ignoring. Getters
> are an implementation detail of an interface.
> Prototypes aren't only useful for sharing behavior. They’re just as useful
> for *data objects and value types*. Nothing breaks when you clone or
> assign them around.
>
> Object.assign just read properties from one object and assign them to
> another. Something you used to do by hand. It’s just shorter to type
> assign(A, B) than type all properties of B out manually. If it’s _not_
> meant to be the function-equivalent of `*for (var key in source)
> target[key] = source[key]*` then that’s too bad as my money is on it’s
> going to be used as such. I definitely want to use it for that.
>
> But what's bugging me every time more, is that somebody had a very bad
> idea to spread `Object.assign` as something good for inheritance or object
> cloning.
>
> Are you dealing with prototypes and `Object.assign` ? You gonna have way
> more problems than a missed flattered structure.
> Can you explain what is your goal ? Wouldn't this work?
>
>
> Inheritance? Inheritance is an implementation detail. A function receiving
> an object must not care about its inheritance tree as long as it fulfills
> the required interface. That’s what the LSP says as well. Even though
> JavaScript has no explicit concept of interfaces or types, they’re implicit
> in any function call.
>
> My goal is to save people from having to think every time they call a
> function whether this 3rd party function ignores inherited properties or
> not. If the callee uses Object.assign, it strips them out, if not, the
> dot-operator takes it into account. Surely no-one’s expecting everyone to
> prefix _every_ obj.name use with hasOwn: `*obj.hasOwnProperty(“name”) &&
> obj.name <http://obj.name>`*. Why do it in Object.assigns then is beyond
> me. Inconsistent and uncalled for.
>
> A.
>
> On Feb 27, 2015, at 14:24, Andrea Giammarchi 
> wrote:
>
> You are talking about "flatting" all properties, which is an undesired
> overhead.
>
> ```js
>
> var b = Object.create(
>   Object.getPrototypeOf(a)
> );
>
> Object.assign(b, a);
>
> ```
>
> But what's bugging me every time more, is that somebody had a very bad
> idea to spread `Object.assign` as something good for inheritance or object
> cloning.
>
> Where does this come from? `Object.assign` retrieves properties and ignore
> getters and setters, is the last tool you want to use as substitution
> principle because it breaks.
>
> `Object.assign` is good only to define enumerable, writable, and
> configurable properties, like configuration or setup objects.
>
> Are you dealing with prototypes and `Object.assign` ? You gonna have way
> more problems than a missed flattered structure.
>
> Can you explain what is your goal ? Wouldn't this work?
>
> ```js
>
> var a = {}; // or anything else
>
> var b = Object.create(
>   Object.getPrototypeOf(a)
> );
>
> Object.getOwnPropertyNames(a).forEach(function (k) {
>   Object.defineProperty(b, k, Object.getOwnPropertyDescriptor(a, k));
> });
>
> ```
>
>
> Best Regards
>
>
>
> On F

Re: Proposal: Additional Meta Properties for ES7

[Andrea Giammarchi]

and yet you haven't removed any anonymous arrow listener. Assign first?
Mostly nobody will do that, it's just less natural then `obj.on(something,
()=>happening)`

On Fri, Feb 27, 2015 at 3:59 PM, Claus Reinke 
wrote:

> Can you show an example of how callee is used with a fat arrow function?
>>>
>> ((n)=>n>1? n*function.callee(n-1) : 1)
>>
>
> meta-level tools are powerful, which makes them ever so tempting.
>
> They are too powerful to be used for tasks for which current
> language-level tools are sufficient. Using a call-by-value fixpoint
> combinator
>
>let fix = f=>x=>f(x=>fix(f)(x))(x)
>undefined
>
> we can use plain functional abstraction instead of meta properties
>
>let f = self=>n=>n>1?n*self(n-1):1
>undefined
>
>fix(f)(6)
>720
>
>fix(f)(7)
>5040
>
> (if you're worried about optimization, provide a built-in 'fix')
>
> For concise methods, the problem is already solved by 'this',
> isn't it?
>
>({f(n){return n>1?n*this.f(n-1):1}}.f)(6)
>720
>
> Like most powerful tempting things, referring to meta-levels comes
> at a cost, even though that may not be immediately visible (ie no
> lexical scoping, cannot extract as part of a function body). So the
> easiest route (of introducing the most powerful feature) is not
> necessarily the best route.
>
> You're still working to get rid of anomalies that hamper functional
> abstraction and composition (arrow functions help with 'this'; and
> wasn't the missing toMethod an attempt to handle the newly introduced
> 'super' special case?). I'm surprised to see everyone so eager to introduce
> new trouble.
>
> just saying... :-)
> Claus
> http://clausreinke.github.com/
>
>
>
> ___
> 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.assign and inherited properties

[Andrea Giammarchi]

answering inline ...

On Fri, Feb 27, 2015 at 2:22 PM, Andri Möll  wrote:

> noone? JSLint doesn't even let you write a for/in loop if you don't have
> `obj.hasOwnProperty(key)` in it, and usually nobody wants inherited
> properties (included methods from old classes/ahem prototypes) reassigned
> everywhere.
>
>
> Huh? Old prototypes? Those prototypes have their properties set as
> non-enumerable since how long now?
>

nope, I was rather talking about user-land defined "classes" through
prototypes. in ES3 these are all enumerable, you don't want methods copied
all over your objects each time because that's the entire point of having
prototypal inheritance, right? If instead of inheriting and composing you
copy everything as enumerable, writable, and configurable, that's your
choice, not what I believe we all need.




> You yourself said one shouldn’t use Object.assign for objects with
> behavior in the inheritance chain. And I agree. It’s pretty much only
> useful for data objects (a.k.a plain). Those have no methods in the
> inheritance chain one needs to ignore.
>

meaning you are good to go with assign or the function I wrote for you.




>
> Again, I ask, *what is the problem to which ignoring inherited properties
> is the solution to?*
>
>

[ 1 ] What is the problem in accessing inherited values?

If you don't want to distinguish them, just don't and use a for/in

Why do you want now to change Object assign instead of simply using for/in?
This requirement is available since 1999




> I posit everyone wants inherited properties. Just half of the people have
> been FUDed into being afraid of inheritance. But arguments based on
> assumptions on what other people want are irrelevant because naive people
> are easy to influence.
>

You seem to be afraid of inheritance since you want to ignore it and flat
all the properties per each copied/enriched object.
I am back with previous [ 1 ] question then.




> JSLint is how Douglas Crockford writes his code. That’s not an argument
> for right APIs. JSON.stringify is equally retarded with its inconsistent
> handling of inheritance, but that’s another matter.
>

You can define you r`toJSON` method that returns the result of the for/in
based function I've written for you. Is that retarded?

Moreover, you can recreate instances at parse time with a specialized
reviver: https://gist.github.com/WebReflection/87e41c09691edf9432da
Is that retarded? ( maybe this one is :P )



>
> And as I said below: until everyone also prefixes their obj.name uses
> with hasOwn: `*obj.hasOwnProperty(“name”) && obj.name <http://obj.name>`*,
> skipping inherited properties is a fool’s errand. It causes *inconsistent
> APIs* because you don’t run your options et alii objects through
> inheritance strippers every time. And you shouldn’t. Or does anyone
> disagree with that?
>

actually, following your logic you should never access that unless you are
sure it's also enumerable so ...

`*obj.hasOwnProperty("name")** && **obj.propertyIsEnumerable("name")
&& **obj.name
<http://obj.name/>`*`



>
> This is a bigger problem than my use of Object.assign. Proliferation of
> Object.assign will prevent everyone else from relying on inheritance. And
> in a prototypal language I find that bad API design.
>

Precisely !  So use inheritance instead of flattening/hiding it everywhere.
Use dictionaries and for/in when all this does not matter.

I really don't see, with all possibilities you have to write the way you
want, and a function I wrote for you that does what you need, why bothering
`Object.assign`

Best Regards




>
> A.
>
> On Feb 27, 2015, at 15:40, Andrea Giammarchi 
> wrote:
>
> noone? JSLint doesn't even let you write a for/in loop if you don't have
> `obj.hasOwnProperty(key)` in it, and usually nobody wants inherited
> properties (included methods from old classes/ahem prototypes) reassigned
> everywhere.
>
> If you deal with data objects and dictionaries yuo'll always have a flat
> structure, right? If you don't care about properties descriptors (getters
> and setters) you can always use a for/in
>
> ```
> function flatEnumerables(a) {
>   for (var c, k, i = 1; i < arguments.length; i++) {
> for (k in (c = arguments[i])) a[k] = c[k];
>   }
>   return a;
> }
> ```
> This would do what you are looking for (which is the first time I
> personally read/hear about somebody wanting `Object.assign` to behave like
> a for/in)
>
> Would that work?
>
> Best Regards
>
>
>
> On Fri, Feb 27, 2015 at 12:56 PM, Andri Möll  wrote:
>
>> You are talking about "flatting" all properties, which is an undesired
>> overhea

Re: Function "name" property

[Andrea Giammarchi]

Mark many framewors/libraries/younameit attach listeners at construction
time, there is where everyone feels like it's cool and fast and better, and
shorter to use arrow functions, then they have to mix between removable
listeners and not.

I personally pass objects as listeners, providing an `handleMethod` so that
I never need to address functions or methods to be able to remove a
listener via an event, unfortunately when nodejs was born developers didn't
know this way of adding listeners so that's not even an option in node.

Having arrows functions with all these "refactoring caveats" doesn't feel
smart because you always want to be able to re-schedule a setTimeout, you
always want to be able to have a recursion without trusting the context
that could be just undefined (or the global one if transpiled in older
engines) and you always want to be eventually able to drop a listener in
certain circumstances ... or at least, that's the reason I still try to
avoid using arrows functions.

For "greppability sake", code consistency and reliability, a callee like
feature would be a good solution for all cases.

We had this before, and it was useful. It got lost together with other
things that were not as useful and secure at the same time.

Then if it's just me, feel free to ignore my thoughts on callee.


Best Regards







On Fri, Feb 27, 2015 at 4:34 PM, Mark Miller  wrote:

> Why do arrow functions need to reflect on themselves? I think it is more
> useful for all code "directly" inside a non-arrow function to be able to
> reflect on that non-arrow function. If I wrote an arrow function and then
> found I wanted it to reflect on itself, I'd be happier rewriting it as a
> non-arrow function than I would with either
> * the complexity of a whole new set of special forms for arrow functions
> to reflect on themselves, or
> * (as in the original proposal) making it more difficult for code in an
> arrow function to reflect on their containing non-arrow function.
>
>
>
> On Fri, Feb 27, 2015 at 8:00 AM, Rick Waldron 
> wrote:
>
>>
>>
>> On Thu Feb 26 2015 at 8:22:55 PM Claude Pache 
>> wrote:
>>
>>>
>>> > Le 27 févr. 2015 à 02:04, Allen Wirfs-Brock  a
>>> écrit :
>>> >
>>> >
>>> > On Feb 26, 2015, at 3:55 PM, Mark S. Miller wrote:
>>> >> For most of these, my first reaction is meh. They all make sense and
>>> violate no principle, but are they worth it?
>>> >>
>>> >> I do not like the arrow function behavior. For anything named
>>> function.something occurring within an arrow function, I'd expect it to be
>>> about the lexically enclosing non-arrow function. I do not object to the
>>> idea that there be such a special form that is about the arrow function,
>>> but it needs to be spelled differently. I have no concrete suggestion
>>> though.
>>> >
>>> > We have to work with the reserved words we have available,  there
>>> really need to apply equivalently to all functions, arrow or otherwise
>>> defined.  The only other available keyword that seems at all suggest of
>>> these use cases is 'in'
>>> >
>>> > in.callee  (or whatever)
>>> > in.count.
>>> > in.arguments
>>> >
>>> > If we went that route I'd probably still stick with 'function.next'
>>> for that use case
>>> >
>>> > Allen
>>>
>>> That one has just popped in my mind :-)
>>>
>>> =>.arguments
>>>
>>>
>> I was thinking exactly this while I was reading Allen's post.
>>
>> Would class method definitions use `class.*`? Seems like the wrong
>> abstraction..? Maybe all functions and method definitions use `function`,
>> while arrows use `=>` (or whatever) to preserve correspondence to
>> possible outer function?
>>
>> Rick
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Text by me above is hereby placed in the public domain
>
>   Cheers,
>   --MarkM
>
> ___
> 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.assign and inherited properties

[Andrea Giammarchi]

te
> functions or APIs that use Object.assign while setting their defaults. I
> don’t mind them flattening, but only if they don’t lose half of the
> properties to inheritance stripping while doing so.
>
> Am I explaining the problem wrong? I’m still surprised there are people
> who don’t find the following behavior retarded:
>
> ```
> function logPerson(person) { console.log(“%s is from %s.”, person.name,
> person.country) }
> function logTraveler(person) { logPerson(Object.assign({name:
> “Traveller”}, person)) }
>
> var PERSON = {name: “Unnamed”, country: “Estonia"}
> var john = Object.create(PERSON)
> john.name = “John”
>
> logPerson(john) // => John is from Estonia.
> logTraveler(john) // => John is from undefined.
> ```
>
> While a little contrived, like I said, Object.assign and its equivalents
> from libraries are already used to set defaults.
> Just in case: please don’t propose replacing every Object.create with
> Object.assign.
>
> A.
>
> On Feb 27, 2015, at 18:35, Andrea Giammarchi 
> wrote:
>
> answering inline ...
>
> On Fri, Feb 27, 2015 at 2:22 PM, Andri Möll  wrote:
>
>> noone? JSLint doesn't even let you write a for/in loop if you don't have
>> `obj.hasOwnProperty(key)` in it, and usually nobody wants inherited
>> properties (included methods from old classes/ahem prototypes) reassigned
>> everywhere.
>>
>>
>> Huh? Old prototypes? Those prototypes have their properties set as
>> non-enumerable since how long now?
>>
>
> nope, I was rather talking about user-land defined "classes" through
> prototypes. in ES3 these are all enumerable, you don't want methods copied
> all over your objects each time because that's the entire point of having
> prototypal inheritance, right? If instead of inheriting and composing you
> copy everything as enumerable, writable, and configurable, that's your
> choice, not what I believe we all need.
>
>
>
>
>> You yourself said one shouldn’t use Object.assign for objects with
>> behavior in the inheritance chain. And I agree. It’s pretty much only
>> useful for data objects (a.k.a plain). Those have no methods in the
>> inheritance chain one needs to ignore.
>>
>
> meaning you are good to go with assign or the function I wrote for you.
>
>
>
>
>>
>> Again, I ask, *what is the problem to which ignoring inherited
>> properties is the solution to?*
>>
>>
>
> [ 1 ] What is the problem in accessing inherited values?
>
> If you don't want to distinguish them, just don't and use a for/in
>
> Why do you want now to change Object assign instead of simply using
> for/in? This requirement is available since 1999
>
>
>
>
>> I posit everyone wants inherited properties. Just half of the people have
>> been FUDed into being afraid of inheritance. But arguments based on
>> assumptions on what other people want are irrelevant because naive people
>> are easy to influence.
>>
>
> You seem to be afraid of inheritance since you want to ignore it and flat
> all the properties per each copied/enriched object.
> I am back with previous [ 1 ] question then.
>
>
>
>
>> JSLint is how Douglas Crockford writes his code. That’s not an argument
>> for right APIs. JSON.stringify is equally retarded with its inconsistent
>> handling of inheritance, but that’s another matter.
>>
>
> You can define you r`toJSON` method that returns the result of the for/in
> based function I've written for you. Is that retarded?
>
> Moreover, you can recreate instances at parse time with a specialized
> reviver: https://gist.github.com/WebReflection/87e41c09691edf9432da
> Is that retarded? ( maybe this one is :P )
>
>
>
>>
>> And as I said below: until everyone also prefixes their obj.name uses
>> with hasOwn: `*obj.hasOwnProperty(“name”) && obj.name
>> <http://obj.name/>`*, skipping inherited properties is a fool’s errand.
>> It causes *inconsistent APIs* because you don’t run your options et alii
>> objects through inheritance strippers every time. And you shouldn’t. Or
>> does anyone disagree with that?
>>
>
> actually, following your logic you should never access that unless you are
> sure it's also enumerable so ...
>
> `*obj.hasOwnProperty("name")** && **obj.propertyIsEnumerable("name") && 
> **obj.name
> <http://obj.name/>`*`
>
>
>
>>
>> This is a bigger problem than my use of Object.assign. Proliferation of
>> Object.assign will prevent everyone else from relying on inheritance. An

Re: Proposal: Additional Meta Properties for ES7

[Andrea Giammarchi]

nope, you are limiting your object to have only one listener per event, I
think that's not quite how reality is. You gonna lose that listeners next
time somebody use same name with the same object.

In (?:io|node)js you have EventEmitter that exposes .on, on web even jQuery
needs that reference in order to be able to remove only that listener
instead of many.

Sure you have .once or .one that might help here, but removing a listener
can also be performed for other reasons.

If there's no way developers will find their own, but it makes arrow
function less attractive, at least to my eyes




On Fri, Feb 27, 2015 at 6:04 PM, Claus Reinke 
wrote:

> and yet you haven't removed any anonymous arrow listener. Assign first?
>> Mostly nobody will do that, it's just less natural then `obj.on(something,
>> ()=>happening)`
>>
>
> personally? Yes, I tend to assign listeners somewhere, at least when I
> intend to remove them later. I've even been known to assign them to a
> virtual event object, so that I could translate the event names later
> (eg, click vs touch). But that is just me.
>
> One could also hide the assignment in an `on` helper (JQuery does
> something similar).
>
>function on (obj,event,listener) {
>obj._events[event]=listener;
>return obj.on(event,listener);
>}
>
> Claus
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Additional Meta Properties for ES7

[Andrea Giammarchi]

I think the fact you had to write two solutions where one attach to the
object the listener and another one needs a double arrow (rainbow) already
shows we have a hole in the language once covered by arguments.callee.

The more you write examples, the more you convince me we are missing callee
;-)

Again, this is jut my opinion. There are ways to work around this, it just
feels wrong we lost the callee feature.

Regards

On Fri, Feb 27, 2015 at 7:48 PM, Claus Reinke 
wrote:

>
> > nope, you are limiting your object to have only one listener per event,
> I think that's not quite how reality is. You gonna lose that listeners next
> time somebody use same name with the same object.
>
> true. For cases where that isn't enough, i assume you're thinking of
> canceling from within the handler.
>
> Here goes another attempt, preserving identity while providing a
> self-reference.
>
> let arg = ff=>{
>   let arg = {};
>   let f = ff(arg);
>   arg.callee = f;
>   return f;
> };
> let f = arg=>n=>n>1?n*arg.callee(n-1):1;
> console.log(arg(f)(5));
>
> Perhaps i'm going to run out of ideas soon, but my point is that it is
> worth looking for less powerful alternatives that achieve the same ends.
> Else we'd all be writing lisp, right?-)
>
> Claus
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.assign and inherited properties

[Andrea Giammarchi]

assign` is the wrong
method/tool/function to do anything prototypal or classical inheritance
related.

Developers should understand it, and I am realizing they don't ... like not
at all!

Best Regards



>
> A.
>
> On Feb 27, 2015, at 19:51, Andrea Giammarchi 
> wrote:
>
> That is not what people relying in Object.assign and ES6 will write,
> because you cannot define properties in a generic class, only methods.
>
> Moreover, back to your ES5/3compat example, if you have a person object,
> you **never** inherit name, you always have your own name as you explicitly
> set "John".
>
> You eventually inherit the surname, but that's indeed not your own so it
> should not be copied as such, it should stay there inherited unless you
> explicitly go to the inheritance office (the property descriptor officer)
> and ask for an own surname.
>
> Same is for all people from Estonia, they all inherit their native country
> when born, they have to hide it explicitly at the same "descriptor office"
> in order to make them their own country.
>
> But all this goes down to why/how/where you need to retrieve these info.
> That is the place you log through a for/in in order to reach all exposed
> (read enumerables) properties.
> That is where you log passing whatever it is through the function I've
> written.
>
> Before? country isan accessible info, as the surname and other inherited
> properties eventually would be, and only if re-set on top, will become own
> properties.
>
> At the end of the day, `Object.assign` has been already adopted and
> polyfilled and used for some time now, changing it now will probably break
> all code based on it.
>
> Again, I think this is the first time I hear someone wanting a new method
> being exactly like a for/in ... use for/in if that's what you need ( KISS ?
> )
>
> Best Regards
>
>
> On Fri, Feb 27, 2015 at 5:27 PM, Andri Möll  wrote:
>
>> ES3 these are all enumerable, you don't want methods copied all over your
>> objects each time because that's the entire point of having prototypal
>> inheritance, right? If instead of inheriting and composing you copy
>> everything as enumerable, writable, and configurable, that's your choice,
>> not what I believe we all need.
>>
>>
>> Umm, that’s one tactic for sharing behavior. Yep. But I thought we agreed
>> Object.assign is more useful for data/record objects than for objects with
>> behavior. Ignoring inheritance because of methods is not an argument then.
>>
>> You yourself said one shouldn’t use Object.assign for objects with
>>> behavior in the inheritance chain. And I agree. It’s pretty much only
>>> useful for data objects (a.k.a plain). Those have no methods in the
>>> inheritance chain one needs to ignore.
>>>
>>
>> meaning you are good to go with assign or the function I wrote for you.
>>
>>
>> Sadly not. Inheritance should not be conflicted with sharing behavior
>> (methods). Entirely orthogonal concepts. It’s very useful to inherit from
>> various data/record objects and pass those around. The receiver of such an
>> object need never know there’s inheritance involved.
>>
>> [ 1 ] What is the problem in accessing inherited values?
>> If you don't want to distinguish them, just don't and use a for/in
>> Why do you want now to change Object assign instead of simply using
>> for/in? This requirement is available since 1999
>>
>>
>> They thing to remember here is _other people’s code_. My code perfectly
>> honors your inheritance chains when iterating or accessing properties. But
>> me doing that doesn’t imply everyone else won’t use Object.assign to set up
>> their defaults as is very convenient: `person = Object.assign({name: “”,
>> age: 0}, person)`. You think they won’t? They already do so with
>> Object.keys when it’s entirely unnecessary for 9/10 use-cases.
>>
>> You seem to be afraid of inheritance since you want to ignore it and flat
>> all the properties per each copied/enriched object.
>> I am back with previous [ 1 ] question then.
>>
>>
>> Nah, I’m saying inheritance is an implementation detail of my object.
>> It’s none of the receiver’s/callee’s business how I implemented that
>> particular interface (any agreed upon set of properties _is_ an interface).
>> But the moment someone passes my object to Object.assign, they get the
>> wrong output. Even if it should’ve been a no-op: `options =
>> Object.assign({}, options)`.
>>
>> You can define you r`toJSON` method that returns the result of the for/in
>> based func

Re: Object.assign and inherited properties

[Andrea Giammarchi]

I think your issue is not real, since the bug you linked is indeed closed
and the one you opened has been exhaustively answered bu John who's the
main person behind lo-dash, the drop-in replacement for underscore.
https://github.com/joyent/node/issues/7587#issuecomment-42560846

and the "let it go" part is the one I'd like to +1
https://github.com/joyent/node/issues/7587#issuecomment-42677422

There's nothing to add here, and this came after a discussion/link you
should probably have linked before.

I understand your library was born believing `Object.assign` would have
been the answer to all your problems, I'm afraid JS descriptors and
inheritance are a bit more complicated than just own, enumerable, writable,
properties.

Best Regards

On Fri, Feb 27, 2015 at 10:30 PM, Andri Möll  wrote:

> `Object.assign` has **nothing to do with inheritance**, that's what I am
> saying, not just supporting.
>
> What is my personal position here is that `Object.assign` is the wrong
> method/tool/function to do anything prototypal or classical inheritance
> related.
>
>
> Are we entirely missing each other? I’ve said a few times now: it’s _none_
> of the callee’s business if I use inheritance in my options, config, setup
> or any other plain object (one without behavior). Object.assign must honor
> that.
>
> I asked in my first email: *What is the problem to which ignoring
> inherited properties is the solution to?*
> If you have an argument that I haven’t refuted yet, please share.
>
> Just search GitHub’s code for assign usage and you’ll see it fucking up
> inheritance all over the place.
> There’s even a IO.js issue for the same problem that I’m definitely going
> to help fix: https://github.com/iojs/io.js/issues/62.
>
> Andri Möll:
>
> Nah, I’m saying inheritance is an implementation detail of my object. It’s
>>> none of the receiver’s/callee’s business how I implemented that particular
>>> interface (any agreed upon set of properties _is_ an interface). But the
>>> moment someone passes my object to Object.assign, they get the wrong
>>> output. Even if it should’ve been a no-op: `options = Object.assign({},
>>> options)`.
>>>
>>
> Ignores getters? You mean merely reads them? That’s not ignoring. Getters
>>>>> are an implementation detail of an interface.
>>>>>
>>>> Prototypes aren't only useful for sharing behavior. They’re just as
>>>>> useful for *data objects and value types*. Nothing breaks when you
>>>>> clone or assign them around.
>>>>>
>>>>
> Inheritance? Inheritance is an implementation detail. A function receiving
>>>>> an object must not care about its inheritance tree as long as it fulfills
>>>>> the required interface. That’s what the LSP says as well. Even though
>>>>> JavaScript has no explicit concept of interfaces or types, they’re 
>>>>> implicit
>>>>> in any function call.
>>>>>
>>>>
> A.
>
> On Feb 27, 2015, at 23:13, Andrea Giammarchi 
> wrote:
>
> FWIW I do like prototypal inheritance ... but ...
>
> On Fri, Feb 27, 2015 at 8:45 PM, Andri Möll  wrote:
>
>> That is not what people relying in Object.assign and ES6 will write,
>> because you cannot define properties in a generic class, only methods.
>>
>>
>> Classes are just syntactic sugar over prototypes after all.
>>
>
> except finally these behave like natives always have: non enumerable
> methods / accessors ... those that even you said don't want on your way
>
>
>
>> I’m definitely going to continue promoting use of plain old prototypical
>> approaches in addition to that because they're simple and elegant:
>>
>
> objects will still be used for composing and whenever you
> `Object.create(Object.getPrototypeOf(other))` you are still using
> prototypal inheritance.
>
> None of this has ever been solved in `Object.assign` though ...
>
>
>
>> why waste computation power in constructors when you can do so once on
>> the prototype.
>>
>
> 'cause 99% of the time you need to initialize your PERSON with a `name`
> property, as example ... do that in the object creation through an implicit
> initializer as constructor is: done!
>
>
>
>> I find that an advantage of prototypal languages over classical ones.
>>
>
> I guess you like `init` methods too then
>
>
>
>
>>
>> A bit of a plug in this regard, check out this simple observable
>> implementation that supports inheritance:
>> https://github.com/moll/js-concert
>> Boy does this save c

Re: Object.assign and inherited properties

[Andrea Giammarchi]

lodash has more downloads than underscore and it does not suffer these kind
of "little gotchas":
https://twitter.com/jdalton/status/568575738086993920

It's a huge community and JD agrees with Leon Arnott points, after all
points he, me, and others, alrThiseady made about this matter.

This discussion landed here after tons of bikesheds already, and I'm fool
enough to keep answering but few already probably thought "get a room" or
something similar, so I'll happily stop here.

This is the outcome from my point of view:
https://twitter.com/WebReflection/status/571442010265149441

Please try to understand you are targeting the wrong method to implement
what you suggest, or feel free to explain to everyone here how inheritance
should work in JS, I'm pretty sure we all don't have a clue so you can tell
us how is that.

Best Regards


On Fri, Feb 27, 2015 at 10:52 PM, Andri Möll  wrote:

> Oh, I’ve forgotten we’ve had this argument with _you_ over at the Node.js
> bug a while back. Long time no see.
>
> 1) Did you even read the issue I linked to? It ended with _agreement_ that
> IO.js _should_ support inherited properties.
> 2) @jdalton did _not_ “exhaustively” answer with arguments relating to
> inheritance. He’s fortunately not someone to give final statements in
> Node.js behavior, and even if he were, discussions need to be over
> arguments and not on personalities or someone’s feelings. This isn’t
> kindergarten.
> 3) There are more people in the world than us two to, so even if you and I
> reach a standstill, it doesn’t mean this shouldn’t be further discussed and
> acted upon.
>
> Saying Object.assing assign is so because of Lodash.assign and
> Lodash.assign is so because of Object.assign is circular and meaningless.
> This thread here is precicely criticism of Object.assign’s behavior and
> needs to be discussed with arguments and counter-arguments relating only to
> inheritance.
>
> Ignore my utility libraries. I don’t want to write libraries for a living.
> :-)
>
> I understand your library was born believing `Object.assign` would have
> been the answer to all your problems, I'm afraid JS descriptors and
> inheritance are a bit more complicated than just own, enumerable, writable,
> properties.
>
>
> [citation needed]. Seriously. Please share your counter-arguments and if I
> can, I’ll counter them or if not, agree. Relating to Object.assign in this
> thread, of course.
>
> A.
>
> On Feb 28, 2015, at 00:40, Andrea Giammarchi 
> wrote:
>
> I think your issue is not real, since the bug you linked is indeed closed
> and the one you opened has been exhaustively answered bu John who's the
> main person behind lo-dash, the drop-in replacement for underscore.
> https://github.com/joyent/node/issues/7587#issuecomment-42560846
>
> and the "let it go" part is the one I'd like to +1
> https://github.com/joyent/node/issues/7587#issuecomment-42677422
>
> There's nothing to add here, and this came after a discussion/link you
> should probably have linked before.
>
> I understand your library was born believing `Object.assign` would have
> been the answer to all your problems, I'm afraid JS descriptors and
> inheritance are a bit more complicated than just own, enumerable, writable,
> properties.
>
> Best Regards
>
> On Fri, Feb 27, 2015 at 10:30 PM, Andri Möll  wrote:
>
>> `Object.assign` has **nothing to do with inheritance**, that's what I am
>> saying, not just supporting.
>>
>> What is my personal position here is that `Object.assign` is the wrong
>> method/tool/function to do anything prototypal or classical inheritance
>> related.
>>
>>
>> Are we entirely missing each other? I’ve said a few times now: it’s
>> _none_ of the callee’s business if I use inheritance in my options, config,
>> setup or any other plain object (one without behavior). Object.assign must
>> honor that.
>>
>> I asked in my first email: *What is the problem to which ignoring
>> inherited properties is the solution to?*
>> If you have an argument that I haven’t refuted yet, please share.
>>
>> Just search GitHub’s code for assign usage and you’ll see it fucking up
>> inheritance all over the place.
>> There’s even a IO.js issue for the same problem that I’m definitely going
>> to help fix: https://github.com/iojs/io.js/issues/62.
>>
>> Andri Möll:
>>
>> Nah, I’m saying inheritance is an implementation detail of my object.
>>>> It’s none of the receiver’s/callee’s business how I implemented that
>>>> particular interface (any agreed upon set of properties _is_ an interface).
>>>> But the moment som

Re: Function "name" property

[Andrea Giammarchi]

but how would you drop that listener, if that's even a concern of yours,
beside the usage of `function`?

Does "I agree with Mark" means already two think arrows function should
never be self-reference-able?

Just a genuine question, thanks

On Sat, Feb 28, 2015 at 12:37 AM, Brendan Eich  wrote:

> Rick Waldron wrote:
>
>> function Component(target) {
>>   let a = function.arguments;
>>
>> target.on("click", event => {
>> // In here, `arguments` refers to the `arguments` object
>> // that was created for this invocation of Component,
>> // which makes sense because that object has no sense of
>> // contextual qualification (something of a legacy problem).
>> function.arguments[0] === a[0]; // false
>>
>> // ...because `function.arguments` here is for this arrow function.
>>   });
>> }
>>
>
> Joke's not funny if you have to explain it.
>
> Seriously, I don't buy the explanation. I read the above and I see
> `function`used twice. I expect the first use declares Component, and the
> second (even though in an arrow, because arrows uphold Tennent's
> Correspondence Principal with respect to `this` and `arguments`) to refer
> to the activation of the function declared by the first use of that
> f-keyword.
>
> I agree with Mark.
>
> /be
>
> ___
> 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: Function "name" property

[Andrea Giammarchi]

FWIW `in` looks good to me, it's self explanatory , but `in.self` or
`in.current` don't look god anymore. Would it be utterly insane to have
`in.function` and `function.function` to reference to the function? If
`in.function` works as `function.function` outside arrows, same as
`in.count` reference to `function.count` outside arrows, then developers
would probably always use the `in.function` version all the time and,
when/if needed, have the ability to go `function.function`

I know latter sounds redundant, but it completes well with the `in` meta
name I personally wouldn't mind.

Regards

On Sat, Feb 28, 2015 at 5:28 PM, Allen Wirfs-Brock 
wrote:

>
> On Feb 28, 2015, at 9:07 AM, Brendan Eich wrote:
>
>
> No, again, I'm objecting to Allen's just-so story that `function` in an
> arrow refers to the arrow, and agreeing with Mark that the pellucid meaning
> (if there is one) would be the TCP one: the enclosing function around the
> arrow (if there is a function).
>
> We need to get to the bottom of this to make progress, in any case. I
> don't think we should jump to `=>.self` for arrows and `function.self` for
> functions, although that is an obvious "patch" to resolve the conflict.
> Patching to split forms and "do both" is often the wrong thing.
>
>
> If you want both a TCP-able from and a local (most closely enclosing
> callable thing) form then the later should also presumably also be
> applicable at the top level of functions.
>
> The 'in'  meta property prefix in combination with the 'function'  prefix
> could do that job:
>
> let foo=function () {
>  function.count;  //the number of actual arguments pass to current
> invocation of foo
>  in.count; //same value as function.count
>  () => {
>   function.count; //the number of actual arguments pass to
> invocation of foo captured by this arrow
>   in.count;//the numer of actual arguments passed to
> this invocation of this arrow
>   }
> };
>
> Allen
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Cancellation architectural observations

[Andrea Giammarchi]

> the rare cancellation case

abort is not a rare case, and an ignore that does not abort makes no sense
whatsoever.

If I am paying data and I've requested 10 tiles on a mobile maps based
sites and I search/go/locate somewhere else on the other edge on the world
it makes no sense to wait for the initial 10 tiles to downloads: either
because my cache won't hold them anyway due settings limitations or browser
behavior, or because I won't see the new location until new tiles requests
are queued behind old tiles.

We can drop downloads on XHR, there is a whatwg Fetch API proposal that is
based on network requests and AFAIK it does not provide a way to be
canceled (being Promise based)

A mechanism that tries to abort, instead of faking it, allows a faking
(read: ignore) logic to be implemented regardless, but not the other way
round.

Moreover, being sure about the end of the Network operation is a real-world
problem but not solvable here for the simple reason that my mobile network
could die anytime in the process, with or without ignored Promises.

So that maye my rejected error was triggered after the server already
updated ... how are we going to solve this anyway?

If the POST didn't explicitly complete, we could let the server know about
it with a lighter request, instead of keep sendong 25MB of image that you
realized is the wrong one ...
So, having real reactions on cancel/abort should be the only option, IMO,
so that we can solve explicit developers intent.

As summary: as a developer, I don't know yet which way is the best one, but
if there's a way to interrupt the execution, however it's going to be
called, I am expecting such explicit action to be done, and not to be
silently ignored, specially from the underlying logic ( network requests,
POST requests, download, preload, etc )

Please let's get this right, thank you.




On Mon, Mar 2, 2015 at 6:25 PM, Dean Tribble  wrote:

> On Mon, Mar 2, 2015 at 6:32 AM, Gray Zhang  wrote:
>
>> +1 to the ignore term, I’ve opened an issue about it in
>> https://github.com/promises-aplus/cancellation-spec/issues/14
>>
> I have little attachment to any term, but there's value in keeping
> terminology that has years of investment and use in other contexts. However
> "ignore" also has the wrong sense, because it implies that the computation
> completes anyway. That can be accomplished more easily by simply dropping
> the promise.
>
>> IMO the term cancel(or abort) and ignore are totally different things,
>> the former one means “do not continue, stop it right now” and the “stop”
>> state should be broadcast to everyone who is interested in the work, while
>> the latter means “I don’t care about the result anymore, just play it as
>> you like”, it means the async progress can be continued
>>
>  This goes back to some of the observations above: you cannot stop it
> "right now" because async notification is not synchronous; indeed the
> operation may already be complete before you stop it. Thus consumers of the
> result of a cancellable request need to be able to handle either successful
> completion or the cancelled state (which just looks like any other error
> that prevented completion).  Attempting broadcast to "everyone" adds
> complexity and resources that are needed only in the rare cancellation
> case. It's typically not only not worth the software complexity, but not a
> good idea. When you cancel a print job, the document editor should make
> best efforts in the background to stop requesting fonts, stop laying out
> print pages, stop spitting out pages on the printer, etc. but most
> importantly, it should start paying attention to my new edits and hang
> waiting for everything that might be involved in printing to wrap itself up.
>
>> In practice both scenario are commonly seen, we may abort a resource
>> fetch in order to save bandwidth and opened connections, or we may in other
>> side just ignore it since continue to complete the fetch can result in a
>> local cache, which speeds up our fetch next time
>>
> The resource point is important. That's the "don't care" scenario, not the
> "abort" scenario. It's the request processor that knows what cleanup is
> worth the effort. The initiator of the request only knows they don't care
> about the result anymore.
>
> ___
> 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: iterator next method returning new object

[Andrea Giammarchi]

about preventing jerkiness around the object passed around ...

with some logic similar to this one:

```js
function proxiedOwnValues(obj) {
  return Object.freeze(Object.keys(obj).reduce(function (o, k) {
return Object.defineProperty(o, k, {
  get: function () {
return obj[k];
  }
});
  }, Object.create(null)));
}
```

we can have one object per generator, and one passed around via `.next()`
so that

```js
// not exposed
var internal = {value: undefined, done: false};

// returned via .next()
var passedAround = proxiedOwnValues(internal);

// when the value gets updated
internal.value = 123;

// is reflected in the outer world
passedAround.value; // 123

// when everything is done
internal.done = true;

// is reflected as well
passedAround.done; // true

```

So we have preserved contract, people stopping polluting objects they don't
own, and read only operations that could be optimized even more behind the
scene.

Does any of this make sense?

Best Regards




On Mon, Mar 2, 2015 at 7:06 PM, Jason Orendorff 
wrote:

> The most important things here are:
>
> 1.  Like all performance hacks, unless you've measured a speed
> improvement under fairly realistic workloads, you shouldn't do this.
>
> 2.  Whenever you need a custom iterator, try writing a generator
> instead. It's amazing. You can get the behavior you want in a fraction
> of the developer time, with clearer and *much* smaller code.
>
> As to your question, here are some (additional) seeds of doubt as
> requested:
>
> -   Storing this object isn't entirely free. You have to create a
> property (or closed-over variable, same deal, roughly) to stash it in,
> and each time .next() is called, you have to access that property or
> variable. Also, storing the object prevents the most-recently-iterated
> value from being GC'd. (Normally this won't matter. It could matter if
> you have thousands of iterators going at once, and each one is only
> occasionally consulted.)
>
> -   If the caller is a jerk, they might do something like freeze the
> object (which means your .next() method will keep getting called
> forever, since it can't set .done to true) or replace the .value
> property with an accessor, and then perhaps your next() method would
> throw or something. You probably never care about stuff like this, and
> that's OK. Certain very rare users do have to care. Worse, your JS
> engine's JIT does have to care.
>
> -   The statement `return {value: v, done: false};` can't fail,
> whereas `cachedObject.value = v` can fail, in the unlikely cases
> described above, or can trigger a setter, and therefore may require
> your JS engine to check something each time you do it. That's extra
> work and it could slow things down.
>
> -   The JS engine might be smart enough (if not now, then a year down
> the road) to optimize away the temporary object created by `return
> {value: v, done: false};`. If it does, then using a new object is
> probably better for your JS engine's optimizer, because getting .value
> or .done off of that object is *guaranteed* to produce `v` and
> `false`, respectively, with no side effects and no possibility of
> triggering any getters, setters, proxy traps, etc.
>
> -j
>
> On Sat, Feb 28, 2015 at 4:52 PM, Mark Volkmann
>  wrote:
> > I know there was a discussion about this recently, but I don't recall
> seeing a reason why it would be problem for a custom iterator to return the
> same object over and over with different values for the value and done
> properties. I tried this in some sample code using Traceur and Babel and it
> works fine. What are the potential problems with doing that?
> >
> > ---
> > R. Mark Volkmann
> > Object Computing, Inc.
> > ___
> > 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Cancellation architectural observations

[Andrea Giammarchi]

So this is my simplified view of the matter ... it already works, and it
aborts eventually with the ability to ignore the onabort callback.

The config object can have `onabort` that activates the "abort-ability",
the `onprogress` so that eventually this promise inside a generator can
still update UIs, and potentially any other sort of property but for demo
sake just `method` for GET, HEAD, PUT, POST and other requests.

```js
function fetch(url, config) {
  config || (config = {});
  var
xhr = new XMLHttpRequest,
promise = new Promise(function (res, rej) {
  xhr.addEventListener('error', function (pe) { rej(xhr); });
  xhr.addEventListener('load', function (pe) { res(xhr); });
  if (config.onabort)
xhr.addEventListener('abort', config.onabort);
  if (config.onprogress)
xhr.addEventListener('progress', config.onprogress);
  xhr.open(config.method || 'GET', url, true);
  xhr.send(null);
})
  ;
  if (config.onabort)
promise.abort = xhr.abort.bind(xhr);
  return promise;
}
```

abort example:
`fetch('?page', {onabort: console.warn.bind(console)}).abort();`

with progress too
`fetch('?page', {onabort: console.warn.bind(console), onprogress:
console.log.bind(console)}).abort();`

full request
`fetch('?page', {onabort: console.warn.bind(console), onprogress:
console.log.bind(console)}).then(console.log.bind(console));`

Why this code? Simply to somehow show that I am all for getting this right,
but to me it's also probably a simpler matter than it looks like, specially
for cases where cancel or abort is meant and needed.

Best Regards


On Mon, Mar 2, 2015 at 7:45 PM, Ron Buckton  wrote:

>  ​
>
> In light of *Async Functions* in ES7, it may make sense to separate the
> abstractions between promises and cancellation. Promises and cancellation
> signals have different use cases:
>
>
>  *Promises*
>
>- Promises are *consumed* by the caller and *produced* by the callee.
>- Observation a promise resolution can only happen in a *later * turn.
>- The consumer of a promise *cannot* directly resolve the promise.
>
> *Cancellation*
>
>- Cancellation signals are *produced* by the caller and * consumed* by
>the callee.
>- Observation a cancellation signal must happen *immediately*.
>- The consumer of a cancellation token *cannot* directly cancel the
>token.
>
> *API Proposal:*
>
>
>  class CancellationTokenSource {
>   /** Create a new CTS, optionally with an iterable of linked cancellation
> tokens. */
>   constructor(linkedTokens?: Iterable);
>
>   /** Gets the cancellation token for this source. */
>   get token(): CancellationToken;
>
>   /** Cancels the source and sends a cancellation signal with an optional
> reason (default Error("Operation canceled")). */
>   cancel(reason?: any): void;
>
>   /** Cancels the source after a delay (in milliseconds), with an optional
> reason. */
>   cancelAfter(delay: number, reason?: any): void;
>
>   /** Prevents any possible future cancellation of the source and removes
> all linked registrations. */
>   close(): void;
> }
>
> class CancellationToken {
>   /** Gets a cancellation token that can never be canceled. */
>   static get default(): CancellationToken;
>   /** Gets a value indicating whether the cancellation signal was sent. */
>   get canceled(): boolean;
>   /** If canceled, gets the reason for cancellation if provided;
> otherwise, returns `undefined`. */
>   get reason(): any;
>   /** If canceled, throws either the reason or a general “Operation
> Canceled” error. */
>   throwIfCanceled(): void;
>   /**
> * Registers a callback to execute immediately when a cancellation
> signal is received.
> * The callback can be removed using the `unregister` method of the
> return value.
> */
>   register(callback: (reason: any) => void): { unregister(): void };
> }
>
>
>  *Usage (Abort):*
>
>
>  ```
> // aborts and throws error when canceled
> function fetchAsync(url, cancellationToken = CancellationToken.default) {
>   return new Promise((resolve, reject) => {
> cancellationToken.throwIfCanceled();
> var xhr = new XMLHttpRequest();
> var registration = cancellationToken.register(() => xhr.abort());
> xhr.open("GET", url, /*async*/ true);
> xhr.onload = event => {
> registration.unregister();
> resolve(xhr.responseText);
> };
> xhr.onerror = event => {
> registration.unregister();
> reject(xhr.statusText);
> }
> xhr.send(null);
>   });
> }
>
> fetchAsync(...).then(...); // as expected
>
> var cts1 = new CancellationTokenSource();
> fetchAsync(..., cts1.token).catch(...);
> cts1.cancel(new Error("Operation Canceled"); // .catch gets the error and
> the xhr is aborted.
>
>
>  *Usage (Ignore):*
>
>
>  // ignore operation/stop processing
> async function startTicker(receiveSymbol, cancellationToken =
> CancellationToken.default) {
> while (!cancellationToken.canceled) {
> var symbols = await fetchSymbols();

Re: Accepting an array as the first parameter to String.prototype.includes

[Andrea Giammarchi]

I'm still having hard time understanding what's the difference between
contains and the good old indexOf beside the RegExp check ... but I agree
having multiple explicit searches instead of multiple implicit searches
won't make such big difference. Good news is, you probably will still use
RegExp anyway because names can be composed and haveing a \bName\b helper
is probably what you might need anyway :-)

i.e. Maria !== Marianne

On Tue, Mar 10, 2015 at 3:31 PM, Bergi  wrote:

> Edwin Reynoso wrote:
>
> > There are times where I would like to check whether a string has every
> > occurrence of certain strings/numbers:
> >
> > Now to achieve what I would like `String.prototype.includes` to
> accomplish
> > with an array as the first parameter, I currently take the following
> > approach:
> >
> > var str = "John,Mary,Bob,Steve";
> > var names = ["Mary", "Bob"];
> > names.every(name => str.includes(name)); // true;
>
> And that's perfectly fine imho, pretty expressive about what is done about
> the array. Just passing an array to `.includes` is rather meaningless (not
> denotative).
>
> If we need a method to do this (to allow for native optimisations with
> fancy string search algorithms), I'd suggest to use a different method name
> like `String.prototype.includesAll`.
>
>  Bergi
> ___
> 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: Accepting an array as the first parameter to String.prototype.includes

[Andrea Giammarchi]

contains better than indexOf ? I'd agree only if contains wasn't accepting
any extra argument, which makes it even more (pointless?) similar to
indexOf.

If it had only one incoming parameter, you could have `["maria",
"marianne"].some(str.contains, str)` and win over all other examples. but
just the `!=-1` or `>-1` as reason to prefer contains? ... dunno, I think I
have 99 problems in JS related development, `>-1` ain't one :-/

On Tue, Mar 10, 2015 at 8:42 PM, Garrett Smith 
wrote:

> On 3/10/15, Andrea Giammarchi  wrote:
> > I'm still having hard time understanding what's the difference between
> > contains and the good old indexOf beside the RegExp check ... but I agree
> > having multiple explicit searches instead of multiple implicit searches
> > won't make such big difference. Good news is, you probably will still use
> > RegExp anyway because names can be composed and haveing a \bName\b helper
> > is probably what you might need anyway :-)
> >
> > i.e. Maria !== Marianne
> >
>
> What if Array had a contains or containsAll functions?
>
>  var s = "Maria, Mariana";
>  var a = s.split(/\s*,\s*/);
>  ["Maria", "Mariana"].every(e=>{return a.indexOf(e)!=-1});
>  true
>
> But a `contains` function might be better than indexOf
>
>  ["Maria", "Mariana"].every(e=>{return a.contains(e)});
>
> But `containsAll` might be even better.
>
>  a.containsAll(["Maria", "Mariana"]) seems even easier to read for me.
>
> There is already `filter` for exclusions. What about merging arrays?
>
> Array.union(array2, array3, ...);
>
>
> > On Tue, Mar 10, 2015 at 3:31 PM, Bergi  wrote:
> >
> >> Edwin Reynoso wrote:
> >>
> >> > There are times where I would like to check whether a string has every
> >> > occurrence of certain strings/numbers:
> >> >
> >> > Now to achieve what I would like `String.prototype.includes` to
> >> accomplish
> >> > with an array as the first parameter, I currently take the following
> >> > approach:
> >> >
> >> > var str = "John,Mary,Bob,Steve";
> >> > var names = ["Mary", "Bob"];
> >> > names.every(name => str.includes(name)); // true;
> >>
> >> And that's perfectly fine imho, pretty expressive about what is done
> >> about
> >> the array. Just passing an array to `.includes` is rather meaningless
> >> (not
> >> denotative).
> >>
> >> If we need a method to do this (to allow for native optimisations with
> >> fancy string search algorithms), I'd suggest to use a different method
> >> name
> >> like `String.prototype.includesAll`.
> >>
> >>  Bergi
> >> ___
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >
>
>
> --
> Garrett
> @xkit
> ChordCycles.com
> garretts.github.io
> personx.tumblr.com
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Accepting an array as the first parameter to String.prototype.includes

[Andrea Giammarchi]

also, just for people not afraid of the tilde

`["Maria", "Mariana"].some(e=>~a.indexOf(e));`

yeah, you can use it ^_^


On Tue, Mar 10, 2015 at 9:34 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> contains better than indexOf ? I'd agree only if contains wasn't accepting
> any extra argument, which makes it even more (pointless?) similar to
> indexOf.
>
> If it had only one incoming parameter, you could have `["maria",
> "marianne"].some(str.contains, str)` and win over all other examples. but
> just the `!=-1` or `>-1` as reason to prefer contains? ... dunno, I think I
> have 99 problems in JS related development, `>-1` ain't one :-/
>
> On Tue, Mar 10, 2015 at 8:42 PM, Garrett Smith 
> wrote:
>
>> On 3/10/15, Andrea Giammarchi  wrote:
>> > I'm still having hard time understanding what's the difference between
>> > contains and the good old indexOf beside the RegExp check ... but I
>> agree
>> > having multiple explicit searches instead of multiple implicit searches
>> > won't make such big difference. Good news is, you probably will still
>> use
>> > RegExp anyway because names can be composed and haveing a \bName\b
>> helper
>> > is probably what you might need anyway :-)
>> >
>> > i.e. Maria !== Marianne
>> >
>>
>> What if Array had a contains or containsAll functions?
>>
>>  var s = "Maria, Mariana";
>>  var a = s.split(/\s*,\s*/);
>>  ["Maria", "Mariana"].every(e=>{return a.indexOf(e)!=-1});
>>  true
>>
>> But a `contains` function might be better than indexOf
>>
>>  ["Maria", "Mariana"].every(e=>{return a.contains(e)});
>>
>> But `containsAll` might be even better.
>>
>>  a.containsAll(["Maria", "Mariana"]) seems even easier to read for me.
>>
>> There is already `filter` for exclusions. What about merging arrays?
>>
>> Array.union(array2, array3, ...);
>>
>>
>> > On Tue, Mar 10, 2015 at 3:31 PM, Bergi  wrote:
>> >
>> >> Edwin Reynoso wrote:
>> >>
>> >> > There are times where I would like to check whether a string has
>> every
>> >> > occurrence of certain strings/numbers:
>> >> >
>> >> > Now to achieve what I would like `String.prototype.includes` to
>> >> accomplish
>> >> > with an array as the first parameter, I currently take the following
>> >> > approach:
>> >> >
>> >> > var str = "John,Mary,Bob,Steve";
>> >> > var names = ["Mary", "Bob"];
>> >> > names.every(name => str.includes(name)); // true;
>> >>
>> >> And that's perfectly fine imho, pretty expressive about what is done
>> >> about
>> >> the array. Just passing an array to `.includes` is rather meaningless
>> >> (not
>> >> denotative).
>> >>
>> >> If we need a method to do this (to allow for native optimisations with
>> >> fancy string search algorithms), I'd suggest to use a different method
>> >> name
>> >> like `String.prototype.includesAll`.
>> >>
>> >>  Bergi
>> >> ___
>> >> es-discuss mailing list
>> >> es-discuss@mozilla.org
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >>
>> >
>>
>>
>> --
>> Garrett
>> @xkit
>> ChordCycles.com
>> garretts.github.io
>> personx.tumblr.com
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Accepting an array as the first parameter to String.prototype.includes

[Andrea Giammarchi]

not sure I understand what you say but `["maria",
"marianne"].some(str.contains,
str)` means `["maria", "marianne"].some(function (value) {return
this.contains(value)}, str)` ... no bind nor arrow function needed, the
function `str.contains` is executed with `str` as context per each
iteration. Is that confusing? 'cause that's how
some/every/forEach/map/filter work

On Tue, Mar 10, 2015 at 10:18 PM, Garrett Smith 
wrote:

> On 3/10/15, Andrea Giammarchi  wrote:
> > contains better than indexOf ? I'd agree only if contains wasn't
> accepting
> > any extra argument, which makes it even more (pointless?) similar to
> > indexOf.
> >
> > If it had only one incoming parameter, you could have `["maria",
> > "marianne"].some(str.contains, str)` and win over all other examples. but
> > just the `!=-1` or `>-1` as reason to prefer contains? ... dunno, I
> think I
> > have 99 problems in JS related development, `>-1` ain't one :-/
> >
>
> Evidently.
>
> I can only guess that str is a string. Strings don't have a contains
> method, nor was one proposed the call str.contains(str) inside of a
> call to some looks like a confused mistake.
> --
> Garrett
> @xkit
> ChordCycles.com
> garretts.github.io
> personx.tumblr.com
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Converting strings to template strings

[Andrea Giammarchi]

There's no such functionality indeed but you might want to have a look at
this gist: https://gist.github.com/WebReflection/8f227532143e63649804

It gives you the ability to write `'test1 ${1 + 2} test2 ${3 + 4}'
.template();` and read `test1 3 test2 7` or to pass an object similar to
.Net String.format so that your Stack overflow code would be like the
following:

```js

let a = "b:${b}";
let b = 10;

console.log(a.template({b:b}));

// or

console.log(a.template({b:27}));

```

You pass named properties and it works with nested properties too (i.e.
${down.the.road})

It does use Function which is safe, compared to eval, and needed to
eventually de-opt from 'use strict' but of course you could write your own
parser avoiding Function completely.

Finally, I agree it would be nice to be able to have a standard way to
template strings in JS, the templating as it is plays very poorly with
runtime generated strings, using eval for that looks the dirtiest thing on
earth.

Regards



On Sun, Mar 22, 2015 at 10:05 AM, KOLANICH  wrote:

> I needed a functionality but haven't found it.
> See
> https://stackoverflow.com/questions/29182244/convert-a-string-to-a-template-string
> for more details.
> I think that this should be included into standard;
>
>
> Also we need a standard format string functionality like
> https://msdn.microsoft.com/en-us/library/system.string.format.aspx and
> 
> https://docs.python.org/2/library/string.html#string-formatting
>
> ___
> 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: Supporting feature tests directly

[Andrea Giammarchi]

+1 to Kyle proposal, using eval or Function is not even an option in CSP
constrained environments ( unless the relative code is provided as SHA256,
then we need to agree on how such code should look like and share it as
polyfill )

I'd also suggest `Reflect.isValidSyntax` as alternative to
`Reflect.supports` 'cause it's less misleading when it comes to figure out
APIs support and their implementation.

After all, that's exactly what we'd like to know, if a generic syntax will
break or not.

Regards

On Sun, Mar 22, 2015 at 1:00 AM, Kyle Simpson  wrote:

> > I think you're referring to the `eval` function?
>
> Actually, I'm referring to proposing something new that would substitute
> for having to hack feature tests with `eval`.
>
> These are the initial details of my idea, a `Reflect.supports(..)` method:
> https://gist.github.com/getify/1aac6cacec9cb6861706
>
> Summary: `Reflect.supports( "(()=>{})" )` or `Reflect.supports( "let x" )`
> could test **just** for the ability to parse, as opposed to the
> compilation/execution that `eval(..)` does. It'd be much closer to `new
> Function(..)` except without the overhead of needing to actually produce
> the function object (and then have it be thrown away for GC).
>
> This is inspired by
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Parser_API,
> where FF has a `Reflect.parse(..)` method that is somewhat like what I'm
> suggesting, except that for feature tests we don't need the parse tree,
> just a true/false of if it succeeded.
>
> An alternate form would be `Reflect.supports( Symbol.arrowFunction )`,
> where the engine is just specifically saying "yes" I support that feature
> by recognizing it by its unique built-in symbol name.
> ___
> 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: Converting strings to template strings

[Andrea Giammarchi]

Hi Mark, thanks for pointing that out but if I understand the problem
correctly then the snippet I've suggested concatenates strings and will
never produce those problematic syntax errors. Can I say it's still safe?
Or do you think it might have some problem in Safari?

Cheers

On Sun, Mar 22, 2015 at 11:28 AM, Mark S. Miller  wrote:

>
>
> On Sun, Mar 22, 2015 at 6:46 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> There's no such functionality indeed but you might want to have a look at
>> this gist: https://gist.github.com/WebReflection/8f227532143e63649804
>>
>> It gives you the ability to write `'test1 ${1 + 2} test2 ${3 + 4}'
>> .template();` and read `test1 3 test2 7` or to pass an object similar to
>> .Net String.format so that your Stack overflow code would be like the
>> following:
>>
>> ```js
>>
>> let a = "b:${b}";
>> let b = 10;
>>
>> console.log(a.template({b:b}));
>>
>> // or
>>
>> console.log(a.template({b:27}));
>>
>> ```
>>
>> You pass named properties and it works with nested properties too (i.e.
>> ${down.the.road})
>>
>> It does use Function which is safe,
>>
>
>
> Function is safe almost everywhere, but it is worth pointing out
>
> https://bugs.webkit.org/show_bug.cgi?id=106160
> https://bugs.webkit.org/show_bug.cgi?id=131137
> test_CANT_SAFELY_VERIFY_SYNTAX at
> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#3198
> repair_CANT_SAFELY_VERIFY_SYNTAX at
> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#4170
>
> After the repair, the Function constructor is safe again on Safari, but at
> considerable expense.
>
>
>
>
>> compared to eval, and needed to eventually de-opt from 'use strict' but
>> of course you could write your own parser avoiding Function completely.
>>
>> Finally, I agree it would be nice to be able to have a standard way to
>> template strings in JS, the templating as it is plays very poorly with
>> runtime generated strings, using eval for that looks the dirtiest thing on
>> earth.
>>
>> Regards
>>
>>
>>
>> On Sun, Mar 22, 2015 at 10:05 AM, KOLANICH  wrote:
>>
>>> I needed a functionality but haven't found it.
>>> See
>>> https://stackoverflow.com/questions/29182244/convert-a-string-to-a-template-string
>>> for more details.
>>> I think that this should be included into standard;
>>>
>>>
>>> Also we need a standard format string functionality like
>>> https://msdn.microsoft.com/en-us/library/system.string.format.aspx and
>>> <https://docs.python.org/2/library/string.html#string-formatting>
>>> https://docs.python.org/2/library/string.html#string-formatting
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Converting strings to template strings

[Andrea Giammarchi]

the snippet is extremely simplified and just works for 99.9% of cases it's
meant to be used, a way to provide properties via objects within a string
used as template. The string should not be parsed in the wild, same you
won't evaluate ever string templates without knowing the source. Of course
if you use strings to implement eval like logic you are doing it wrong and
makes no sense to use the template but again, that snippets provides what's
not possible with string templates.

To Mark S. Miller, the strict is a must have for the `with` statement, that
snippets works down to IE5 so I don't actually see or understand your
surprise.

Of course I can implement a full syntax parser instead but then I'd loose
on size, simplicity, and portability (performance)

String templates are not good for templates, these work only for statically
defined code and in place meaning you cannot grab content from a DB and
inject values like names or numbers as you would do with any templating
system.

So what is your suggested solution?



On Sun, Mar 22, 2015 at 11:50 AM, Mark Miller  wrote:

> The pattern  [\S\s]*? admits a lot. Why are you confident that it can't
> contain a string that, for example, closes the function with an unbalanced
> "}", then  has an evil expression which evaluates, followed by an
> unbalanced "{" so the whole thing still parses?
>
> On Sun, Mar 22, 2015 at 7:38 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> Hi Mark, thanks for pointing that out but if I understand the problem
>> correctly then the snippet I've suggested concatenates strings and will
>> never produce those problematic syntax errors. Can I say it's still safe?
>> Or do you think it might have some problem in Safari?
>>
>> Cheers
>>
>> On Sun, Mar 22, 2015 at 11:28 AM, Mark S. Miller 
>> wrote:
>>
>>>
>>>
>>> On Sun, Mar 22, 2015 at 6:46 AM, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
>>>> There's no such functionality indeed but you might want to have a look
>>>> at this gist:
>>>> https://gist.github.com/WebReflection/8f227532143e63649804
>>>>
>>>> It gives you the ability to write `'test1 ${1 + 2} test2 ${3 + 4}'
>>>> .template();` and read `test1 3 test2 7` or to pass an object similar
>>>> to .Net String.format so that your Stack overflow code would be like the
>>>> following:
>>>>
>>>> ```js
>>>>
>>>> let a = "b:${b}";
>>>> let b = 10;
>>>>
>>>> console.log(a.template({b:b}));
>>>>
>>>> // or
>>>>
>>>> console.log(a.template({b:27}));
>>>>
>>>> ```
>>>>
>>>> You pass named properties and it works with nested properties too (i.e.
>>>> ${down.the.road})
>>>>
>>>> It does use Function which is safe,
>>>>
>>>
>>>
>>> Function is safe almost everywhere, but it is worth pointing out
>>>
>>> https://bugs.webkit.org/show_bug.cgi?id=106160
>>> https://bugs.webkit.org/show_bug.cgi?id=131137
>>> test_CANT_SAFELY_VERIFY_SYNTAX at
>>> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#3198
>>> repair_CANT_SAFELY_VERIFY_SYNTAX at
>>> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#4170
>>>
>>> After the repair, the Function constructor is safe again on Safari, but
>>> at considerable expense.
>>>
>>>
>>>
>>>
>>>> compared to eval, and needed to eventually de-opt from 'use strict' but
>>>> of course you could write your own parser avoiding Function completely.
>>>>
>>>> Finally, I agree it would be nice to be able to have a standard way to
>>>> template strings in JS, the templating as it is plays very poorly with
>>>> runtime generated strings, using eval for that looks the dirtiest thing on
>>>> earth.
>>>>
>>>> Regards
>>>>
>>>>
>>>>
>>>> On Sun, Mar 22, 2015 at 10:05 AM, KOLANICH  wrote:
>>>>
>>>>> I needed a functionality but haven't found it.
>>>>> See
>>>>> https://stackoverflow.com/questions/29182244/convert-a-string-to-a-template-string
>>>>> for more details.
>>>>> I think that this should be included into standa

Re: Converting strings to template strings

[Andrea Giammarchi]

Mark, is really deadly simple 5 lines of code script which aim is to access
properties without having conflicts with names (using `with(this)`) without
needing SES or anything else in, without needing to change, it's simplified
string templating that works with dynamic strings.

Why do we need dynamic strings? Because internationalization, just to name
one.

```js
// your lang object
var lang = {
  en: {
greetings: 'Hello ${name}!'
  },
  it: {
greetings: 'Ciao ${name}!'
  }
};

// one i18n string to show
var greetings = lang[user.lang].greetings;

// there you go
alert(greetings.template(user));
```

The current gist is even overenginered because accepts an optional replacer
per each property but the concept is the following:

```js

function getString() {
  with (this) return name;
}

alert('Ciao ' + getString.call({name: 'Mark'}) + '!');

```

It has been used for I think about 10 years in most famous templating
solutions out there because it's a simple and pragmatic approach.
I don't see real-world harm on it, just convenient ease.

Of course performance is not optimal and of course you don't pass user
defined strings there but even doing so I don't see any difference from
opening a console writing down whatever that is. It's Function, and thanks
gosh still capable of giving `with` ability which in this case I think is
extremely convenient.

However, now I am curious about how would access those properties without
using `with` and avoiding a whole parser for the string.

Thanks and Best Regards



On Mon, Mar 23, 2015 at 6:55 AM, Mark S. Miller  wrote:

>
>
> On Sun, Mar 22, 2015 at 10:27 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> the snippet is extremely simplified and just works for 99.9% of cases
>> it's meant to be used, a way to provide properties via objects within a
>> string used as template. The string should not be parsed in the wild, same
>> you won't evaluate ever string templates without knowing the source. Of
>> course if you use strings to implement eval like logic you are doing it
>> wrong and makes no sense to use the template but again, that snippets
>> provides what's not possible with string templates.
>>
>> To Mark S. Miller, the strict is a must have for the `with` statement,
>> that snippets works down to IE5 so I don't actually see or understand your
>> surprise.
>>
>> Of course I can implement a full syntax parser instead but then I'd loose
>> on size, simplicity, and portability (performance)
>>
>
> Of course. SES's confine function <
> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#901>
> does not use a parser on any browser with adequate ES5 support, i.e., any
> modern browser. Even on Safari, it compensates for Safari's code injection
> vulnerabilities <https://bugs.webkit.org/show_bug.cgi?id=106160> using
> the verifyStrictFunctionBodyByEvalThrowing trick at <
> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#914>.
> Even at the 100x slowdown compared to 'new Function(...)' which we use on
> other browsers, it is still much cheaper than doing our own parse -- if
> nothing else, by virtue of not needing to download a parser.
>
>
>>
>> String templates are not good for templates, these work only for
>> statically defined code and in place meaning you cannot grab content from a
>> DB and inject values like names or numbers as you would do with any
>> templating system.
>>
>
> I still don't understand this. Could you give a simple example and explain
> what it is trying to do? Thanks.
>
>
>
>>
>> So what is your suggested solution?
>>
>
> If it is indeed well motivated not to use templating, and to eval
> user-provided code strings, then use SES's confine.
>
> The implementation of SES's confine does resort to an internal bit of
> sloppy code in order to do a 'with', like your's. But SES puts the
> user-provided source string inside a strict function nested within this
> 'with'. See securableWrapperSrc at <
> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#702>.
> No user-provided string is parsed in sloppy mode (except for the
> ugly-but-harmless double check in verifyStrictFunctionBodyByEvalThrowing
> needed to allow lexically nested functions).
>
> SES needs to resort to a 'with' because it uses the scope object to
> emulate an ES5 global scope, where the global variables/properties change
> over time. In your case, are you interested in a chan

Re: Converting strings to template strings

[Andrea Giammarchi]

Even a function wouldn't scale that well for i18n purpose, 'cause you
should write either a function per language or each language switch
statement per function.

I see current ES6 string templates good for debug purpose only, and not
much else ... maybe English centric developers tools so few, definitively
good use cases, but nothing that useful or powerful for the known Web.

```

var template = ``Hello ${name} !``;

template({name: 'there'}); // Hello there !

```

But I know, double back-tick might look too like double rainbow: "OMG what
does it mean" ??!

Regards



On Mon, Mar 23, 2015 at 9:29 PM, Brendan Eich  wrote:

> Jason Orendorff wrote:
>
>> But from the few data points I have, approximately 100% of web
>> developers, when they first hear "template strings are in ES6", think
>> that means something like Mustache in the standard library. Some
>> initially try to use the feature that way and get frustrated. I expect
>> widespread confusion on this point.
>>
>
> This.
>
> A function wrapped around a template string, where the function's
> parameters occur in embedded expressions, goes a long way. But you have to
> write the function, after teaching people the basics and apologizing for
> misleading them with the t-word.
>
> /be
>
> ___
> 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: Iterating default function arguments

[Andrea Giammarchi]

I think the main concern was:

> Currently I can't see a way of getting default parameters as an iterable
object.

 and indeed `arguments` is not the magic variable you are looking for.

However, you are inside your own defined function so either you don't
specify defaults, or you iterate over `[a, b]` ?

Interesting enough, there's no actually a way to understand the function
signature, in terms of optionally accepted arguments.

`arguments.length` is one and same is for `foo.length` so if we'd like to
understand if anyone invoked the function passing or not all optional
parameters, how could we proceed?

Lets say `foo` would like to delegate its own arguments including defined
defaults to another function ... how can we grab these at runtime?

I think the answer is still a static `[a, b]` as list of arguments to
apply, but I can see some lack of "reflection" capability ... or maybe
Reflect would solve this?

Regards




On Wed, Mar 25, 2015 at 4:56 PM, Rick Waldron 
wrote:

>
>
> On Wed, Mar 25, 2015 at 2:40 AM Robin Cafolla 
> wrote:
>
>> Hi there,
>>
>> I was wondering if there were any plans to modify `arguments` to include
>> default parameters (e.g. changing it from a simpleParameterList) or to
>> include a new property that does allow iteration of all values available to
>> a function.
>>
>> for example:
>>
>> function foo( a, b = 2 ) {
>> return arguments;
>> }
>>
>> console.log( foo( 1 ) ); // outputs [ 1 ], not [ 1, 2 ]
>>
>> Currently I can't see a way of getting default parameters as an iterable
>> object.
>>
>> I filed a bug with Mozilla over this, but they pointed out that the
>> behaviour matches the spec.
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1144672
>>
>
>
> This is correct, because only one _argument_ was passed, therefore the
> arguments object has only one entry. Parameters are not the same as
> Arguments.
>
> Therefore:
>
>   foo(1, 3) => [1, 3]
>
> Because two arguments were passed. And:
>
>   foo(1, 2, 3) => [1, 2, 3]
>
> Because three were passed.
>
> Hopefully that helps clarify?
>
> 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: Iterating default function arguments

[Andrea Giammarchi]

Sounds good to me and makes perfect sense. Robin?

On Wed, Mar 25, 2015 at 5:23 PM, Brendan Eich  wrote:

> Andrea Giammarchi wrote:
>
>> I think the answer is still a static `[a, b]` as list of arguments to
>> apply, but I can see some lack of "reflection" capability ... or maybe
>> Reflect would solve this?
>>
>
> Yes, Reflect -- we want a mirror approach, not more magic object like
> arguments or function.
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Supporting feature tests directly

[Andrea Giammarchi]

For consistency sake I agree, but I come from a world where browsers also
exposed unofficially APIs so that, as James mentioned already, `
Array.prototype.includes` would have returned true and never worked.

I wonder how reliable is `CSS.supports` not just in term of syntax, but
actual usability.

Best Regards

On Wed, Mar 25, 2015 at 7:44 PM, Tab Atkins Jr. 
wrote:

> On Sun, Mar 22, 2015 at 3:59 AM, Andrea Giammarchi
>  wrote:
> > +1 to Kyle proposal, using eval or Function is not even an option in CSP
> > constrained environments ( unless the relative code is provided as
> SHA256,
> > then we need to agree on how such code should look like and share it as
> > polyfill )
> >
> > I'd also suggest `Reflect.isValidSyntax` as alternative to
> > `Reflect.supports` 'cause it's less misleading when it comes to figure
> out
> > APIs support and their implementation.
> >
> > After all, that's exactly what we'd like to know, if a generic syntax
> will
> > break or not.
>
> CSS has an exactly analogous feature already, and calls it
> CSS.supports().  That's a decent reason to stick with supports() as
> the name.
>
> ~TJ
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Cancellation architectural observations

[Andrea Giammarchi]

following up from this
https://github.com/whatwg/fetch/issues/27#issuecomment-86987752 , and most
likely late to the party.

How about cancel-ability done this way ?

```js

var p = new Promise(function (res, rej, cancel) {
  // resolved in 1 second via random value
  var t = setTimeout(res, 1000, Math.random());
  // if meant to be canceled
  // we define internally what to do
  cancel(function () {
clearTimeout(t);
  });
});

// whenever/if needed
p.cancel().then(...);
```

The exposed cancel-ability is arbitrary provided internally so that if
missing, an error is thrown while if provided it sets the internal state of
the promise as `canceled` in case it's different from `resolved` or
`rejected`

It gives the ability to react, if a `then` is attached, or the ability to
ignore, if nothing happens to the returned, non cancel-able, Promise.

This avoids exposing to the outer world what happens inside the Promise and
provides arbitrary ability to cancel one.

A cancel-able Promise is one that defined such behavior, which by default
is throwing if that's not defined internally.
This would solve already many cases I have in mind, via users, or
UserAgent, and legitimately behind the scene without any need to expose any
internal logic.

How to resolve or throw other attached promises? Well, `p.cancel().then()`
resolves, while `p.cancel().throw()` does not. `p.cancel()`, without then
or throw would simply throw away pending promises as explicit `ignore`
intent.

How bad does it look and what am I screwing up in here in terms of Promises
philosophy?

Best Regards







On Wed, Mar 4, 2015 at 8:01 PM, Ron Buckton 
wrote:

> > new Promise(resolve => doLater(resolve, cts.token)).then(handleResult);
> > setImmediate(() => cts.cancel());
>
> >
> > In this scenario cancel would be called right after the resolve method
> > is called, but before handlerResult is called. For this to work with a
> > cancellation token you would need to pass the token to every step in
> > the chain to both stop work being done and to ignore the
> > result/prevent a handler from being called. Wouldn't it be better if
> > the promise chain took care of this for the programmer?
>
> I can be convinced that CancellationToken registrations should be invoked
> asynchronously, though I wonder if then CancellationTokenSource#cancel
> should return a Promise to observe any errors that occur.
>
> Ron
> ___
> 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: Cancellation architectural observations

[Andrea Giammarchi]

OK, just for record sake, I'v ecreated a working example of what I
previously meant.
https://gist.github.com/WebReflection/a015c9c02ff2482d327e

Here a basic example (something that will reject on timeout)
```js

// will be resolvednew Promise(function ($res, $rej, ifCanceled) {
  var internal = setTimeout($rej, 1000);
  ifCanceled(function () {
clearTimeout(internal);
  });
})// will be resolved without executing
.then(
  function () {
console.log('on time');
  },
  function () {
console.log('error');
  }
)
.cancel()// will simply execute and resolve
.then(function () {
  console.log('no time');
});

```

The idea is that a Promise is cancelable **only** if a function that
defines how to cancel is provided, otherwise there's no cancel-ability,
it's a regular Promise, and nothing is exported.

This still grants internal private/hidden cancelability through a
resolution or rejection but it also gives the ability to expose a
`.cancel()` to the outher world.

There's no "forever pending" problem because all Promises involved in the
chain will be silently resolved.
The code might be a bit convolute but it was mainly to provide a playground
and I don't see any real violation of the Promises principles.

The presence of `cancel` and its ability is a contract between the Promise
creator/provider and the external world.

Best Regards



On Fri, Mar 27, 2015 at 5:43 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> following up from this
> https://github.com/whatwg/fetch/issues/27#issuecomment-86987752 , and
> most likely late to the party.
>
> How about cancel-ability done this way ?
>
> ```js
>
> var p = new Promise(function (res, rej, cancel) {
>   // resolved in 1 second via random value
>   var t = setTimeout(res, 1000, Math.random());
>   // if meant to be canceled
>   // we define internally what to do
>   cancel(function () {
> clearTimeout(t);
>   });
> });
>
> // whenever/if needed
> p.cancel().then(...);
> ```
>
> The exposed cancel-ability is arbitrary provided internally so that if
> missing, an error is thrown while if provided it sets the internal state of
> the promise as `canceled` in case it's different from `resolved` or
> `rejected`
>
> It gives the ability to react, if a `then` is attached, or the ability to
> ignore, if nothing happens to the returned, non cancel-able, Promise.
>
> This avoids exposing to the outer world what happens inside the Promise
> and provides arbitrary ability to cancel one.
>
> A cancel-able Promise is one that defined such behavior, which by default
> is throwing if that's not defined internally.
> This would solve already many cases I have in mind, via users, or
> UserAgent, and legitimately behind the scene without any need to expose any
> internal logic.
>
> How to resolve or throw other attached promises? Well, `p.cancel().then()`
> resolves, while `p.cancel().throw()` does not. `p.cancel()`, without then
> or throw would simply throw away pending promises as explicit `ignore`
> intent.
>
> How bad does it look and what am I screwing up in here in terms of
> Promises philosophy?
>
> Best Regards
>
>
>
>
>
>
>
> On Wed, Mar 4, 2015 at 8:01 PM, Ron Buckton 
> wrote:
>
>> > new Promise(resolve => doLater(resolve, cts.token)).then(handleResult);
>> > setImmediate(() => cts.cancel());
>>
>> >
>> > In this scenario cancel would be called right after the resolve method
>> > is called, but before handlerResult is called. For this to work with a
>> > cancellation token you would need to pass the token to every step in
>> > the chain to both stop work being done and to ignore the
>> > result/prevent a handler from being called. Wouldn't it be better if
>> > the promise chain took care of this for the programmer?
>>
>> I can be convinced that CancellationToken registrations should be invoked
>> asynchronously, though I wonder if then CancellationTokenSource#cancel
>> should return a Promise to observe any errors that occur.
>>
>> Ron
>> ___
>> 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: Cancellation architectural observations

[Andrea Giammarchi]

quickly at least one thought: `this` inside a Promise callback, is not the
Promise itself so nothing could possibly work.

Moreover, you are setting an event that does not cancel, it resolves.
Meaning all attached Promised will resolve too which is IMO not what
"cancel" mans in the dictionary.

My code brancches out resolving without executing, it's a **very**
different approach. It solves a forever pending problem, without
triggering. Also, in your example, if I trigger a `cancel` in a promise
created though `then` via the cancelable method, nothing would happen which
is undesired in a chained expected behavior.



On Sun, Mar 29, 2015 at 7:10 PM, Frankie Bagnardi 
wrote:

> I don't think this has been brought up, but isn't what we're doing here
> bubbling an event?  Would it make sense to generalize this to a simple
> event bubbling system?
>
> function cancelableGet(url){
>   const xhr = new XMLHttpRequest();
>   return new Promise(function(resolve, reject){
> xhr.open('get', url);
> xhr
>
> this.on('cancel', reason => {
>   xhr.abort();
>   reject(new CanceldRequest(reason));
>
>   // if we wanted to pass it upwards
>   this.emit('cancel', reason);
> });
>   });
>
> }
>
> cancelableGet('/foo')
> .then(...)
> .emit('cancel');
>
> ​
>
> Our listener would be unbound as soon as the promise in cancelableGet settled.
>
>
> This also allows for non-overlapping names for events (Symbol should be
> permitted), where there may be multiple cancelable things in the chain.
>
> It also allows additional metadata, or different event names when 'cancel'
> can mean multiple things.  For example, a process.  Do we send sigint or
> sigkill to cancel it?
>
> Thoughts?
>
>
>
> On Sun, Mar 29, 2015 at 8:56 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> OK, just for record sake, I'v ecreated a working example of what I
>> previously meant.
>> https://gist.github.com/WebReflection/a015c9c02ff2482d327e
>>
>> Here a basic example (something that will reject on timeout)
>> ```js
>>
>> // will be resolvednew Promise(function ($res, $rej, ifCanceled) {
>>   var internal = setTimeout($rej, 1000);
>>   ifCanceled(function () {
>> clearTimeout(internal);
>>   });
>> })// will be resolved without executing
>> .then(
>>   function () {
>> console.log('on time');
>>   },
>>   function () {
>> console.log('error');
>>   }
>> )
>> .cancel()// will simply execute and resolve
>> .then(function () {
>>   console.log('no time');
>> });
>>
>> ```
>>
>> The idea is that a Promise is cancelable **only** if a function that
>> defines how to cancel is provided, otherwise there's no cancel-ability,
>> it's a regular Promise, and nothing is exported.
>>
>> This still grants internal private/hidden cancelability through a
>> resolution or rejection but it also gives the ability to expose a
>> `.cancel()` to the outher world.
>>
>> There's no "forever pending" problem because all Promises involved in the
>> chain will be silently resolved.
>> The code might be a bit convolute but it was mainly to provide a
>> playground and I don't see any real violation of the Promises principles.
>>
>> The presence of `cancel` and its ability is a contract between the
>> Promise creator/provider and the external world.
>>
>> Best Regards
>>
>>
>>
>> On Fri, Mar 27, 2015 at 5:43 PM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> following up from this
>>> https://github.com/whatwg/fetch/issues/27#issuecomment-86987752 , and
>>> most likely late to the party.
>>>
>>> How about cancel-ability done this way ?
>>>
>>> ```js
>>>
>>> var p = new Promise(function (res, rej, cancel) {
>>>   // resolved in 1 second via random value
>>>   var t = setTimeout(res, 1000, Math.random());
>>>   // if meant to be canceled
>>>   // we define internally what to do
>>>   cancel(function () {
>>> clearTimeout(t);
>>>   });
>>> });
>>>
>>> // whenever/if needed
>>> p.cancel().then(...);
>>> ```
>>>
>>> The exposed cancel-ability is arbitrary provided internally so that if
>>> missing, an error is thrown while if provided it sets the internal state of
>>> the promise as `canceled

Re: Unicode normalization problem

[Andrea Giammarchi]

I think the concern on how people seeing what they see can be understood
from JS is more than valid ...

```js
var foo = '𝐀';
var bar = 'Й';
foo.length; // 2
Array.from(foo).length // 1

bar.length; // 2
Array.from(foo).length // 2
```

Why is that and how to solve?


On Wed, Apr 1, 2015 at 10:32 PM, Mathias Bynens  wrote:

> On Wed, Apr 1, 2015 at 10:30 PM, monolithed  wrote:
> >> What you’re seeing there is not normalization, but rather the string
> >> iterator that automatically accounts for surrogate pairs (treating them
> as a
> >> single unit).
> >
> > ```js
> > var foo = '𝐀';
> > var bar = 'Й';
> > foo.length; // 2
> > Array.from(foo).length // 1
> >
> > bar.length; // 2
> > Array.from(foo).length // 2
> > ```
> >
> > I think this is strange.
> > How to safely work with strings?
>
> It depends on your use case. FWIW, I’ve outlined some examples here:
> https://mathiasbynens.be/notes/javascript-unicode
> ___
> 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: Unicode normalization problem

[Andrea Giammarchi]

```js
foo.length; // 2
Array.from(foo).length // 1

bar.length; // 2
Array.from(bar).length // 2
```

I know already everything you wrote ... now, how to explain to JS users out
there and how to solve?

On Thu, Apr 2, 2015 at 1:04 AM, Boris Zbarsky  wrote:

> On 4/1/15 6:56 PM, Andrea Giammarchi wrote:
>
>> Why is that
>>
>
> Because those are different things.  The first is a single Unicode
> character that happens to be represented by 2 UTF-16 code units.  The
> second is a pair of Unicode characters that are each represented by one
> UTF-16 code unit, but also happen to form a single grapheme cluster
> (because one of them is a combining character).  To complicate things
> further, there is also a single Unicode character that represents that same
> grapheme cluster
>
> String length shows the number of UTF-16 code units.
>
> Array.from works on Unicode characters.  That explains the foo.length and
> Array.from(foo).length results.
>
>  and how to solve?
>>
>
> Can you clearly explain what problem you are trying to solve?
>
> -Boris
>
> ___
> 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: Unicode normalization problem

[Andrea Giammarchi]

and now I also gonna hope that `Array.from(foo).length // 2` wasn't by
accident, instead of `bar` ...

On Thu, Apr 2, 2015 at 1:07 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> ```js
> foo.length; // 2
> Array.from(foo).length // 1
>
> bar.length; // 2
> Array.from(bar).length // 2
> ```
>
> I know already everything you wrote ... now, how to explain to JS users
> out there and how to solve?
>
> On Thu, Apr 2, 2015 at 1:04 AM, Boris Zbarsky  wrote:
>
>> On 4/1/15 6:56 PM, Andrea Giammarchi wrote:
>>
>>> Why is that
>>>
>>
>> Because those are different things.  The first is a single Unicode
>> character that happens to be represented by 2 UTF-16 code units.  The
>> second is a pair of Unicode characters that are each represented by one
>> UTF-16 code unit, but also happen to form a single grapheme cluster
>> (because one of them is a combining character).  To complicate things
>> further, there is also a single Unicode character that represents that same
>> grapheme cluster
>>
>> String length shows the number of UTF-16 code units.
>>
>> Array.from works on Unicode characters.  That explains the foo.length and
>> Array.from(foo).length results.
>>
>>  and how to solve?
>>>
>>
>> Can you clearly explain what problem you are trying to solve?
>>
>> -Boris
>>
>> ___
>> 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: Unicode normalization problem

[Andrea Giammarchi]

Jordan the purpose of `Array.from` is to iterate over the string, and the
point of iteration instead of splitting is to have automagically
codepoints. This, unless I've misunderstood Mathias presentation (might be)

So, here there is a different problem: there are code-points that do not
represent real visual representation ... or maybe, the real problem, is
about broken `Array.from` polyfill?

I wouldn't be surprise in such case ;-)

On Thu, Apr 2, 2015 at 1:22 AM, Jordan Harband  wrote:

> Unfortunately we don't have a String#codepoints or something that would
> return the number of code points as opposed to the number of characters
> (that "length" returns) - something like that imo would greatly simplify
> explaining the differences to people.
>
> For the time being, I've been explaining that some characters are actually
> made up of two, and the [image: 💩] character (it's a fun example to use)
> is an example of two characters combining to make one "code point". It's
> not a quick or trivial thing to explain but people do seem to grasp it
> eventually.
>
> On Wed, Apr 1, 2015 at 4:09 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> and now I also gonna hope that `Array.from(foo).length // 2` wasn't by
>> accident, instead of `bar` ...
>>
>> On Thu, Apr 2, 2015 at 1:07 AM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> ```js
>>> foo.length; // 2
>>> Array.from(foo).length // 1
>>>
>>> bar.length; // 2
>>> Array.from(bar).length // 2
>>> ```
>>>
>>> I know already everything you wrote ... now, how to explain to JS users
>>> out there and how to solve?
>>>
>>> On Thu, Apr 2, 2015 at 1:04 AM, Boris Zbarsky  wrote:
>>>
>>>> On 4/1/15 6:56 PM, Andrea Giammarchi wrote:
>>>>
>>>>> Why is that
>>>>>
>>>>
>>>> Because those are different things.  The first is a single Unicode
>>>> character that happens to be represented by 2 UTF-16 code units.  The
>>>> second is a pair of Unicode characters that are each represented by one
>>>> UTF-16 code unit, but also happen to form a single grapheme cluster
>>>> (because one of them is a combining character).  To complicate things
>>>> further, there is also a single Unicode character that represents that same
>>>> grapheme cluster
>>>>
>>>> String length shows the number of UTF-16 code units.
>>>>
>>>> Array.from works on Unicode characters.  That explains the foo.length
>>>> and Array.from(foo).length results.
>>>>
>>>>  and how to solve?
>>>>>
>>>>
>>>> Can you clearly explain what problem you are trying to solve?
>>>>
>>>> -Boris
>>>>
>>>> ___
>>>> 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
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.find - Proposal for (breaking) change of API

[Andrea Giammarchi]

not sure if off topic but

  * you need a with statement to use lodash like that
  * ... the following ...

```
let found = first(filter(
  map(files, _ => path.resolve(base, _)),
  fs.existsSync
));
```

is a very wasteful pattern ... have you ever heard of `some` ?

```
let found;
some(files, _ => fs.existsSync(found = path.resolve(base, _)) || (found =
'') || false);
```

It could bring few alchemies in ;-)


On Tue, Apr 7, 2015 at 9:14 PM, Alexander Jones  wrote:

> You need lazy sequences aka iterators. They give you the rather optimal:
>
> let found = first(filter(
> map(files, _ => path.resolve(base, _)),
> fs.existsSync
> ));
>
> Libs like lodash and lazy.js provide the bits you need, which are
> actually fairly trivial to build on top of nice new ES6 iterators if you
> want.
>
> Alex
>
>
> On Tuesday, April 7, 2015, Martin Heidegger 
> wrote:
>
>> I am probably very late to the game but I just read about harmonies
>> “Array.prototype.find” and found that it might be worth considering a
>> change in way it works. Its not a drastic change but it would break the
>> compatibility to the current setup. I understand that the chances for this
>> going through will be slim but since I would like to give it a shot anyways:
>>
>> Currently the API uses a callback function that has to return a boolean
>> to identify the item that has been found. This is good because find &
>> findIndex can use the same methods but it also has a drawback.
>>
>> Problem: Say you have a list of items that need to be processed before
>> you know if you “found” the item. Then you will need to process the last
>> item again since there is no way to “keep” the result (A) of the find
>> method or you preprocess all items using map (B) that will require to
>> process all the items even if the first one already matches.
>>
>> Example:
>>
>> (BASE)
>> var files = [“main.md”, “backup.md”]
>> var base = “/my/root"
>>
>> (A)
>> // Specifies `path.resolve` on two places
>> var found = files.find(function (file) {
>>return fs.existsSync(path.resolve(base, file))
>> }))
>> if (found)
>>   found = path.resolve(base, file)
>>
>> (B)
>> // Runs `path.resolve` for all items
>> var found = files.map(function (file) {
>>   return path.resolve(base, file)
>> }).find(fs.existsSync)
>>
>> Proposal (C): I think it might be interesting to have a change of the
>> signature so that the return value is not true/false but the value that
>> actually will be returned (not undefined):
>>
>> (C)
>> var found = files.find(function (file) {
>>file = path.resolve(base, file)
>>if(fs.existsSync(file))
>>  return file
>> });
>>
>> This way the operations would be minimised, it is still few to write and
>> it would make life a bit easier.
>>
>> yours
>> Martin Heidegger
>> ___
>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.find - Proposal for (breaking) change of API

[Andrea Giammarchi]

nope, I know it wasn't the bext example, but if you use Array methods as
iterators examples I think I have a problem understanding what you are
talking about.

What you rote, in a JS Array world, is wasteful, and bad/non-optimal usage
of Array patterns we have/know already.

Maybe that's not the point you are trying to make, but surely mine, and
when I read breaking change API and see non optimal patterns I believe the
vision is not clear for everyone about where we are, and where we are
moving.

Apologies if that's not the reply you were hoping for

On Wed, Apr 8, 2015 at 12:02 AM, Alexander Jones  wrote:

> It's not wasteful if, as I said, they are iterator-consuming functions.
> I'm not sure why you think mutating a closed-over variable is better or
> more efficient code. Email me off list and I'll explain, or just look up
> the Python 3 map and filter (or Python 2 itertools equivalents).
>
>
> On Tuesday, April 7, 2015, Andrea Giammarchi 
> wrote:
>
>> not sure if off topic but
>>
>>   * you need a with statement to use lodash like that
>>   * ... the following ...
>>
>> ```
>> let found = first(filter(
>>   map(files, _ => path.resolve(base, _)),
>>   fs.existsSync
>> ));
>> ```
>>
>> is a very wasteful pattern ... have you ever heard of `some` ?
>>
>> ```
>> let found;
>> some(files, _ => fs.existsSync(found = path.resolve(base, _)) || (found
>> = '') || false);
>> ```
>>
>> It could bring few alchemies in ;-)
>>
>>
>> On Tue, Apr 7, 2015 at 9:14 PM, Alexander Jones  wrote:
>>
>>> You need lazy sequences aka iterators. They give you the rather optimal:
>>>
>>> let found = first(filter(
>>> map(files, _ => path.resolve(base, _)),
>>> fs.existsSync
>>> ));
>>>
>>> Libs like lodash and lazy.js provide the bits you need, which are
>>> actually fairly trivial to build on top of nice new ES6 iterators if you
>>> want.
>>>
>>> Alex
>>>
>>>
>>> On Tuesday, April 7, 2015, Martin Heidegger 
>>> wrote:
>>>
>>>> I am probably very late to the game but I just read about harmonies
>>>> “Array.prototype.find” and found that it might be worth considering a
>>>> change in way it works. Its not a drastic change but it would break the
>>>> compatibility to the current setup. I understand that the chances for this
>>>> going through will be slim but since I would like to give it a shot 
>>>> anyways:
>>>>
>>>> Currently the API uses a callback function that has to return a boolean
>>>> to identify the item that has been found. This is good because find &
>>>> findIndex can use the same methods but it also has a drawback.
>>>>
>>>> Problem: Say you have a list of items that need to be processed before
>>>> you know if you “found” the item. Then you will need to process the last
>>>> item again since there is no way to “keep” the result (A) of the find
>>>> method or you preprocess all items using map (B) that will require to
>>>> process all the items even if the first one already matches.
>>>>
>>>> Example:
>>>>
>>>> (BASE)
>>>> var files = [“main.md”, “backup.md”]
>>>> var base = “/my/root"
>>>>
>>>> (A)
>>>> // Specifies `path.resolve` on two places
>>>> var found = files.find(function (file) {
>>>>return fs.existsSync(path.resolve(base, file))
>>>> }))
>>>> if (found)
>>>>   found = path.resolve(base, file)
>>>>
>>>> (B)
>>>> // Runs `path.resolve` for all items
>>>> var found = files.map(function (file) {
>>>>   return path.resolve(base, file)
>>>> }).find(fs.existsSync)
>>>>
>>>> Proposal (C): I think it might be interesting to have a change of the
>>>> signature so that the return value is not true/false but the value that
>>>> actually will be returned (not undefined):
>>>>
>>>> (C)
>>>> var found = files.find(function (file) {
>>>>file = path.resolve(base, file)
>>>>if(fs.existsSync(file))
>>>>  return file
>>>> });
>>>>
>>>> This way the operations would be minimised, it is still few to write
>>>> and it would make life a bit easier.
>>>>
>>>> yours
>>>> Martin Heidegger
>>>> ___
>>>> 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
>>>
>>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.find - Proposal for (breaking) change of API

[Andrea Giammarchi]

actually never-mind, I got hooked by the "Libs like lodash and lazy.js
provide the bits you need" and thought you were using those functions as if
magically wrapped in a `with` statement ... oh well, sorry for the noise:
keep "iterating"

On Wed, Apr 8, 2015 at 12:28 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> nope, I know it wasn't the bext example, but if you use Array methods as
> iterators examples I think I have a problem understanding what you are
> talking about.
>
> What you rote, in a JS Array world, is wasteful, and bad/non-optimal usage
> of Array patterns we have/know already.
>
> Maybe that's not the point you are trying to make, but surely mine, and
> when I read breaking change API and see non optimal patterns I believe the
> vision is not clear for everyone about where we are, and where we are
> moving.
>
> Apologies if that's not the reply you were hoping for
>
> On Wed, Apr 8, 2015 at 12:02 AM, Alexander Jones  wrote:
>
>> It's not wasteful if, as I said, they are iterator-consuming functions.
>> I'm not sure why you think mutating a closed-over variable is better or
>> more efficient code. Email me off list and I'll explain, or just look up
>> the Python 3 map and filter (or Python 2 itertools equivalents).
>>
>>
>> On Tuesday, April 7, 2015, Andrea Giammarchi 
>> wrote:
>>
>>> not sure if off topic but
>>>
>>>   * you need a with statement to use lodash like that
>>>   * ... the following ...
>>>
>>> ```
>>> let found = first(filter(
>>>   map(files, _ => path.resolve(base, _)),
>>>   fs.existsSync
>>> ));
>>> ```
>>>
>>> is a very wasteful pattern ... have you ever heard of `some` ?
>>>
>>> ```
>>> let found;
>>> some(files, _ => fs.existsSync(found = path.resolve(base, _)) || (found
>>> = '') || false);
>>> ```
>>>
>>> It could bring few alchemies in ;-)
>>>
>>>
>>> On Tue, Apr 7, 2015 at 9:14 PM, Alexander Jones  wrote:
>>>
>>>> You need lazy sequences aka iterators. They give you the rather optimal:
>>>>
>>>> let found = first(filter(
>>>> map(files, _ => path.resolve(base, _)),
>>>> fs.existsSync
>>>> ));
>>>>
>>>> Libs like lodash and lazy.js provide the bits you need, which are
>>>> actually fairly trivial to build on top of nice new ES6 iterators if you
>>>> want.
>>>>
>>>> Alex
>>>>
>>>>
>>>> On Tuesday, April 7, 2015, Martin Heidegger 
>>>> wrote:
>>>>
>>>>> I am probably very late to the game but I just read about harmonies
>>>>> “Array.prototype.find” and found that it might be worth considering a
>>>>> change in way it works. Its not a drastic change but it would break the
>>>>> compatibility to the current setup. I understand that the chances for this
>>>>> going through will be slim but since I would like to give it a shot 
>>>>> anyways:
>>>>>
>>>>> Currently the API uses a callback function that has to return a
>>>>> boolean to identify the item that has been found. This is good because 
>>>>> find
>>>>> & findIndex can use the same methods but it also has a drawback.
>>>>>
>>>>> Problem: Say you have a list of items that need to be processed before
>>>>> you know if you “found” the item. Then you will need to process the last
>>>>> item again since there is no way to “keep” the result (A) of the find
>>>>> method or you preprocess all items using map (B) that will require to
>>>>> process all the items even if the first one already matches.
>>>>>
>>>>> Example:
>>>>>
>>>>> (BASE)
>>>>> var files = [“main.md”, “backup.md”]
>>>>> var base = “/my/root"
>>>>>
>>>>> (A)
>>>>> // Specifies `path.resolve` on two places
>>>>> var found = files.find(function (file) {
>>>>>return fs.existsSync(path.resolve(base, file))
>>>>> }))
>>>>> if (found)
>>>>>   found = path.resolve(base, file)
>>>>>
>>>>> (B)
>>>>> // Runs `path.resolve` for all items
>>>>> var found = files.map(function (file) {
>>>>>   return path.resolve(base, file)
>>>>> }).find(fs.existsSync)
>>>>>
>>>>> Proposal (C): I think it might be interesting to have a change of the
>>>>> signature so that the return value is not true/false but the value that
>>>>> actually will be returned (not undefined):
>>>>>
>>>>> (C)
>>>>> var found = files.find(function (file) {
>>>>>file = path.resolve(base, file)
>>>>>if(fs.existsSync(file))
>>>>>  return file
>>>>> });
>>>>>
>>>>> This way the operations would be minimised, it is still few to write
>>>>> and it would make life a bit easier.
>>>>>
>>>>> yours
>>>>> Martin Heidegger
>>>>> ___
>>>>> 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
>>>>
>>>>
>>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Syntax sugar for partial application

[Andrea Giammarchi]

FWIW: agreed with others, it looks a pretty pointless sugar.
It doesn't seem to bring anything new or "that needed" to the language.

-1 here

On Thu, Apr 9, 2015 at 2:04 PM, liorean  wrote:

> Do we really need it?
> Your «foo(1, ?, 2);» is equivalent to «a=>foo(1,a,2)».
> Your «foo(?, 1, ???);» is equivalent to «(a,...b)=>foo(a,1,...b)».
> Your «foo(1, ???, 2);» is equivalent to «(...a)=>foo(...[1,...a,2])».
>
> Also, the ? token is already taken by the ternary conditional
> operator. Do we really want to overload it here for a nullary
> operator/special form, when we have as low overhead syntax as we
> already do in fat arrows for doing the exact same thing?
> --
> David "liorean" Andersson
> ___
> 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: Final ES6 Draft

[Andrea Giammarchi]

"The final ES6 ECMAScript 2014 .." aka: *The 2015 ECMAScript Language
Specification*

Did I say already putting a year in the name was confusing? :P

Congratulations Allen and thanks to everyone contributing making this
happens.

Best Regards

P.S. little typo in that page ... "This is the final draft of ECME-262 6h
Edition" ... I believe you meant 6th, not just 6h ;-)



On Fri, Apr 17, 2015 at 12:23 AM, Allen Wirfs-Brock 
wrote:

> The final ES6 ECMAScript 2014 specification draft has been completed and
> submitted to the Ecma GA for their consideration and review prior to their
> June vote to approve it as a standard.
>
> The final draft is available at
> http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#final_draft
>
>
> The only significant technical change in this draft is some tweaks to
> completion value generation within iteration statements.  These tweaks
> ensure that unroll a loop does not change the resulting completion values.
>
> Other changes are minor editorial corrections including a few Ecma styling
> conformance issues.
>
> It will still be possible to make a few very minor editorial corrections
> before publishings the standard. So please continue to report any bugs or
> typos you find to bugs.ecmascript.org.
>
> ___
> 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

Putting `global` reference in specs

[Andrea Giammarchi]

We have `window` in DOM land, `self` in Workers, and `global` in most
common server side JS engines ... plus we have this in ES6 specification:

> In addition to the properties defined in this specification the *global*
object may have additional host defined properties. This may include a
property whose value is the *global* object itself; for example, in
the HTML document object model the window property of the *global* object
is the *global* object itself.

Now, accordingly with this madness:

8.5 millions checks for `typeof global`
https://github.com/search?q=%27typeof+global%27&type=Code&ref=searchresults&utf8=

14.1 millions checks for `typeof window`
https://github.com/search?q=%27typeof+window%27&type=Code&ref=searchresults&utf8=

Does anyone have a concrete reason for NOT specifying **global** as
reference to whatever `window` or `self` reference already?

I've suggested to stick this on top of every wen page:
```html
var global=global||this;
```

and this on top of every Worker
```js
var global=global||this;
```

But I'm pretty sure if ECMAScript would have that in specs we might see the
end of the debate and the infamouse `typeof window` or `typeof global`
check.

Thanks in advance for thoughts
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Putting `global` reference in specs

[Andrea Giammarchi]

I know that, reason JSLint complains when used internally instead of
`that`, but `self` is the most misleading name ever for whoever comes from
Python and PHP or mostly any other language + self is **nowehere** in
ECMAScript specifications.

So I'd say we should not have `self` (if stays on global and Worker I don't
actually care) and add a `global` that nobody needs explanation to
understand what it is in JavaScript

On Fri, Apr 17, 2015 at 4:02 PM, Boris Zbarsky  wrote:

> On 4/17/15 10:55 AM, Andrea Giammarchi wrote:
>
>> We have `window` in DOM land, `self` in Workers
>>
>
> We have `self` in DOM land too, so you can consistently use `self` across
> Window and Workers.
>
>  and `global` in most common server side JS engines
>>
>
> Sounds like they should add `self`.  ;)
>
> -Boris
> ___
> 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: Putting `global` reference in specs

[Andrea Giammarchi]

there's actually no way, officially, to reference what ES2015 call *the
global object*, just pointless fragmentation between engines.



On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren  wrote:

> On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
>  wrote:
> > So I'd say we should not have `self` (if stays on global and Worker I
> don't
> > actually care) and add a `global` that nobody needs explanation to
> > understand what it is in JavaScript
>
> Indeed, three ways to reference the global object is not nearly enough.
>
>
> --
> https://annevankesteren.nl/
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Putting `global` reference in specs

[Andrea Giammarchi]

it's a no-go under CSP so it's as bad as `Function('return this')()`

On Fri, Apr 17, 2015 at 4:29 PM, Boris Zbarsky  wrote:

> On 4/17/15 11:27 AM, Mark S. Miller wrote:
>
>> (1,eval)('"use strict"; this')
>>
>
> This has the drawback of making eyes bleed, but the benefit of working
> reliably (unlike "window", "self", or "global") ;)
>
> -Boris
>
> ___
> 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: Putting `global` reference in specs

[Andrea Giammarchi]

also `eval` can be in-scope redefined as much as global, window, or self,
so no, that's actually not a solution.

Btw, I wasn't asking for a workaround, I was proposing to officially bring
ES 2015 `global` object as language reference in ES7/201X

It's a very tiny improvement for every developer benefit ( 8.5 + 14.1
millions of results in Github for `typeof global` apparently got unnoticed )

On Fri, Apr 17, 2015 at 4:33 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> it's a no-go under CSP so it's as bad as `Function('return this')()`
>
> On Fri, Apr 17, 2015 at 4:29 PM, Boris Zbarsky  wrote:
>
>> On 4/17/15 11:27 AM, Mark S. Miller wrote:
>>
>>> (1,eval)('"use strict"; this')
>>>
>>
>> This has the drawback of making eyes bleed, but the benefit of working
>> reliably (unlike "window", "self", or "global") ;)
>>
>> -Boris
>>
>> ___
>> 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: Putting `global` reference in specs

[Andrea Giammarchi]

I've never said unshadowable ... I am saying that `global` should be a
global reference to the global object which is mentioned in ES6/2015 but
it's not specified how it should be referenced. `window` is not welcome
even in DOM tools like browserify, `global` is ubiquitous in its meaning,
it does not confuse anyone like a `self` in node.js or others would do, and
it will solve forever the hassle of referencing *by deafault* a global
object without needing to eval, Function('return this'), [].sort(), or
whatever wizardy you coudl came up to retrieve and/or reference the global
object.

It's deadly simple: whatever freedom implementors have to put window and/or
self in, they MUST put a `global` reference too ... that will make
everything else redundant, in the long term, and not vice-versa

Is this really that complicated to ship?

On Fri, Apr 17, 2015 at 4:42 PM, Mark S. Miller  wrote:

>
>
> On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> also `eval` can be in-scope redefined as much as global, window, or self,
>> so no, that's actually not a solution.
>>
>> Btw, I wasn't asking for a workaround, I was proposing to officially
>> bring ES 2015 `global` object as language reference in ES7/201X
>>
>
> In an unshadowable manner? Never gonna happen. Everything that provides
> authority must be virtualizable.
>
>
>
>>
>> It's a very tiny improvement for every developer benefit ( 8.5 + 14.1
>> millions of results in Github for `typeof global` apparently got unnoticed )
>>
>> On Fri, Apr 17, 2015 at 4:33 PM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> it's a no-go under CSP so it's as bad as `Function('return this')()`
>>>
>>> On Fri, Apr 17, 2015 at 4:29 PM, Boris Zbarsky  wrote:
>>>
>>>> On 4/17/15 11:27 AM, Mark S. Miller wrote:
>>>>
>>>>> (1,eval)('"use strict"; this')
>>>>>
>>>>
>>>> This has the drawback of making eyes bleed, but the benefit of working
>>>> reliably (unlike "window", "self", or "global") ;)
>>>>
>>>> -Boris
>>>>
>>>> ___
>>>> 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
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Putting `global` reference in specs

[Andrea Giammarchi]

oh ... that one, it was for Boris who wrote:

> This has the drawback of making eyes bleed, but the benefit of working
reliably (unlike "window", "self", or "global") ;)

I meant that your `eval` wasn't more reliable than window, self, or global,
because ot could have been redefined as well ... but this is not about
shadowability, it's about having one name that fits in every JS situation:
server, worker, document

`global` instead of `window` and/or `self` is a clear win for everyone,
being curse forever to check it `typeof window` or `typeof global` is not
undefined is ... well, the most basic and striking fragmentation case we
have at the root of the language ^_^



On Fri, Apr 17, 2015 at 5:13 PM, Mark S. Miller  wrote:

>
>
> On Fri, Apr 17, 2015 at 9:05 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> I've never said unshadowable ...
>>
>
> You did:
>
> On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> also `eval` can be in-scope redefined as much as global, window, or self,
>> so no, that's actually not a solution.
>>
>
>
>
>
>
>
>> I am saying that `global` should be a global reference to the global
>> object which is mentioned in ES6/2015 but it's not specified how it should
>> be referenced. `window` is not welcome even in DOM tools like browserify,
>> `global` is ubiquitous in its meaning, it does not confuse anyone like a
>> `self` in node.js or others would do, and it will solve forever the hassle
>> of referencing *by deafault* a global object without needing to eval,
>> Function('return this'), [].sort(), or whatever wizardy you coudl came up
>> to retrieve and/or reference the global object.
>>
>> It's deadly simple: whatever freedom implementors have to put window
>> and/or self in, they MUST put a `global` reference too ... that will make
>> everything else redundant, in the long term, and not vice-versa
>>
>> Is this really that complicated to ship?
>>
>> On Fri, Apr 17, 2015 at 4:42 PM, Mark S. Miller 
>> wrote:
>>
>>>
>>>
>>> On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
>>>> also `eval` can be in-scope redefined as much as global, window, or
>>>> self, so no, that's actually not a solution.
>>>>
>>>> Btw, I wasn't asking for a workaround, I was proposing to officially
>>>> bring ES 2015 `global` object as language reference in ES7/201X
>>>>
>>>
>>> In an unshadowable manner? Never gonna happen. Everything that provides
>>> authority must be virtualizable.
>>>
>>>
>>>
>>>>
>>>> It's a very tiny improvement for every developer benefit ( 8.5 + 14.1
>>>> millions of results in Github for `typeof global` apparently got unnoticed 
>>>> )
>>>>
>>>> On Fri, Apr 17, 2015 at 4:33 PM, Andrea Giammarchi <
>>>> andrea.giammar...@gmail.com> wrote:
>>>>
>>>>> it's a no-go under CSP so it's as bad as `Function('return this')()`
>>>>>
>>>>> On Fri, Apr 17, 2015 at 4:29 PM, Boris Zbarsky 
>>>>> wrote:
>>>>>
>>>>>> On 4/17/15 11:27 AM, Mark S. Miller wrote:
>>>>>>
>>>>>>> (1,eval)('"use strict"; this')
>>>>>>>
>>>>>>
>>>>>> This has the drawback of making eyes bleed, but the benefit of
>>>>>> working reliably (unlike "window", "self", or "global") ;)
>>>>>>
>>>>>> -Boris
>>>>>>
>>>>>> ___
>>>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Cheers,
>>> --MarkM
>>>
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Putting `global` reference in specs

[Andrea Giammarchi]

> As such I think our best bet is for server-side JS runtimes to use `self`
or `window`.

I personally hope that would never happen, and you managed to over-engineer
the simplest alignment requirement I could possibly think of ... indeed ...



> We might as well move it into the set of terms like "realm" or "vat" or
"environment" that are more abstract than real.

a new term like realm will just create more fragmentation =>
https://xkcd.com/927/ + there's no such thing on server side, at least not
the same there is on front end

vat is at least semantic in this case since it means Value-Added Tax ...
but I am back to previous point

environment is confusing with `process.env`



Let's avoid the introduction of more problems please ... I rather leave
things as it is since we are unable to be pragmatic, no matter how straight
forward is the solution.


On Fri, Apr 17, 2015 at 6:11 PM, Domenic Denicola  wrote:

> One thing I'm surprised nobody has brought up yet is that "global" would
> be an incorrect name in the case of browsers. The actual global object is
> not (and must never be) directly accessible. Instead you get a window proxy
> when you use `window`, `self`, `this`, etc.
>
> As such I think our best bet is for server-side JS runtimes to use `self`
> or `window`.
>
> The latter isn't as crazy as it sounds: just start adding phrases to the
> ES spec like "all JavaScript code runs within a certain context, called a
> _window_, which has a corresponding _window object_. In some runtimes the
> window object will be equivalent to the global object, but not always.
> Scripts run within _window scope_, whereas modules run in their own lexical
> context. The value of **this** in window scope is the window object."
>
> It's not as if `window` actually means "window" anymore, given tabs and
> iframes and frames. We might as well move it into the set of terms like
> "realm" or "vat" or "environment" that are more abstract than real.
>
> -Original Message-
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> Anne van Kesteren
> Sent: Friday, April 17, 2015 11:19
> To: Andrea Giammarchi
> Cc: es-discuss@mozilla.org
> Subject: Re: Putting `global` reference in specs
>
> On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
> > So I'd say we should not have `self` (if stays on global and Worker I
> > don't actually care) and add a `global` that nobody needs explanation
> > to understand what it is in JavaScript
>
> Indeed, three ways to reference the global object is not nearly enough.
>
>
> --
> https://annevankesteren.nl/
> ___
> 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: Putting `global` reference in specs

[Andrea Giammarchi]

And that's indeed the only place on Web world where `self` makes sense:
it's referring to the frame (scoped) context its running, not to the `top`
(global) tab wrapper.



On Fri, Apr 17, 2015 at 7:51 PM, Brendan Eich  wrote:

> Just for historians who might not know, when I did ur-JS in 1995, I made
> multiple names for the global, in part because event handlers (which
> prefigured nested functions in general, and added with-like DOM object
> scoping -- a regret); but also in part because  was a
> thing in Netscape 2.
>
> /be
>
>
> Boris Zbarsky wrote:
>
>> On 4/17/15 10:55 AM, Andrea Giammarchi wrote:
>>
>>> We have `window` in DOM land, `self` in Workers
>>>
>>
>> We have `self` in DOM land too, so you can consistently use `self` across
>> Window and Workers.
>>
>>  and `global` in most common server side JS engines
>>>
>>
>> Sounds like they should add `self`.  ;)
>>
>> -Boris
>> ___
>> 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Putting `global` reference in specs

[Andrea Giammarchi]

Sure workers too, but it doesn't in server side and it doesn't mean
anything meaningful for all developers coming from other languages. `self`
is a misleading word and in ES6 specs we have mentioned global object and
never a single word for the `self` keyword, or its meaning.

`global` does not need that kind of explanation you put down for historical
purpose, `global` is well known meaning for everyone in JS world, including
members in this ML that would refer to the global scope, and the global
object, regardless they mean sometimes `realm` ... or isn't it?

On Fri, Apr 17, 2015 at 10:38 PM, Brendan Eich  wrote:

> The principle extends just fine to workers, and has.
>
> /be
>
>
> Andrea Giammarchi wrote:
>
>> And that's indeed the only place on Web world where `self` makes sense:
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Putting `global` reference in specs

[Andrea Giammarchi]

at this point you mean it will never be introduced, not even as alias in
ES7 or ES8, do I understand correctly?

Best Regards

On Sat, Apr 18, 2015 at 5:17 AM, Brendan Eich  wrote:

> We cannot introduce a global property named `global` at this point.
>
> I don't think everyone replying lately has read the whole thread carefully
> :-|.
>
> /be
>
> Andrea Giammarchi wrote:
>
>> Sure workers too, but it doesn't in server side and it doesn't mean
>> anything meaningful for all developers coming from other languages. `self`
>> is a misleading word and in ES6 specs we have mentioned global object and
>> never a single word for the `self` keyword, or its meaning.
>>
>> `global` does not need that kind of explanation you put down for
>> historical purpose, `global` is well known meaning for everyone in JS
>> world, including members in this ML that would refer to the global scope,
>> and the global object, regardless they mean sometimes `realm` ... or isn't
>> it?
>>
>> On Fri, Apr 17, 2015 at 10:38 PM, Brendan Eich > <mailto:bren...@mozilla.org>> wrote:
>>
>> The principle extends just fine to workers, and has.
>>
>> /be
>>
>>
>> Andrea Giammarchi wrote:
>>
>> And that's indeed the only place on Web world where `self`
>> makes sense:
>>
>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Subclassing ES6 objects with ES5 syntax.

[Andrea Giammarchi]

Not exactly ... if it's an Array, as example, the moment you
slice/map/splice/concat, etc will return an instanceof Array, not an
instance of whatever you have sublcassed.

Regards

On Fri, Apr 24, 2015 at 10:24 AM, Alex Kocharin  wrote:

>
> I believe you can subclass anything using code like this:
>
> function MyPromise(executor) {
>   var self = new Promise(executor)
>   self.setPrototypeOf(self, MyPromise.prototype)
>   return self
> }
> Object.setPrototypeOf(MyPromise, Promise)
>
>
> ... and it can be easily subclassed itself in the same way.
>
>
> 24.04.2015, 04:02, "C. Scott Ananian" :
>
> Is there any way to access `new.target` using ES5 syntax?
>
> It appears that the "correct" way to create a subclass using ES5 syntax is:
> ```
> function MyPromise(executor) {
>   var self = Reflect.construct(Promise, [executor], new.target);
>   return self;
> }
> Object.setPrototypeOf(MyPromise, Promise);
> ```
> But since `new.target` isn't accessible, we have to do something like:
> ```
> function MyPromise(executor) {
>   var self = Reflect.construct(Promise, [executor], MyPromise); // <-- THIS
>   return self;
> }
> Object.setPrototypeOf(MyPromise, Promise);
> ```
> which works for only a single level of subclassing.  That is, it allows us
> to create and instantiate MyPromise, but now nobody can subclass
> MyPromise.  That's too bad.
>
> Is there any way around this?
>   --scott
>
> ps. Use case: My `prfun` package on npm subclasses `Promise` in order to
> add all the useful utility helpers without stomping on the global `Promise`
> object.  I'd like to do so in a way which is compatible with both native
> ES6 promises (if they are available) and properly-written ES5 shims.
> ,
>
> ___
> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Subclassing ES6 objects with ES5 syntax.

[Andrea Giammarchi]

So you should do the same with Promise methods but then you'll see overall
a quite consistent performance drop when using all these subclasses.

We've been trying for about 10 years now (
http://dean.edwards.name/weblog/2006/11/hooray/ ) and yet we don't have a
working and performing solution, which I guess is why somebody still
pollutes global prototypes, everything becomes easier, including the
ability to still use common literals to define objects or lists.

Oh well :-)

Best Regards

On Fri, Apr 24, 2015 at 3:26 PM, Alex Kocharin  wrote:

>
> True, but it should be your responsibility (as a person who implements a
> subclass) to resolve those issues.
>
> Thankfully, it's easily done:
>
> ```
> function MyArray(...args) {
>   var self = Array.apply(null, args)
>   Object.setPrototypeOf(self, MyArray.prototype)
>   return self
> }
>
> Object.setPrototypeOf(MyArray.prototype, Array.prototype)
>
> ;[ 'slice', 'map', 'concat' /* whatever else */ ].forEach(function
> (method) {
>   MyArray.prototype[method] = function (...args) {
> var result = Array.prototype[method].apply(this, args)
> Object.setPrototypeOf(result, MyArray.prototype)
> return result
>   }
> })
>
> console.log(MyArray(1).slice(1) instanceof MyArray)
> // true
> ```
>
>
> 24.04.2015, 14:13, "Andrea Giammarchi" :
>
> Not exactly ... if it's an Array, as example, the moment you
> slice/map/splice/concat, etc will return an instanceof Array, not an
> instance of whatever you have sublcassed.
>
> Regards
>
> On Fri, Apr 24, 2015 at 10:24 AM, Alex Kocharin  wrote:
>
>
> I believe you can subclass anything using code like this:
>
> function MyPromise(executor) {
>   var self = new Promise(executor)
>   self.setPrototypeOf(self, MyPromise.prototype)
>   return self
> }
> Object.setPrototypeOf(MyPromise, Promise)
>
>
> ... and it can be easily subclassed itself in the same way.
>
>
> 24.04.2015, 04:02, "C. Scott Ananian" :
>
> Is there any way to access `new.target` using ES5 syntax?
>
> It appears that the "correct" way to create a subclass using ES5 syntax is:
> ```
> function MyPromise(executor) {
>   var self = Reflect.construct(Promise, [executor], new.target);
>   return self;
> }
> Object.setPrototypeOf(MyPromise, Promise);
> ```
> But since `new.target` isn't accessible, we have to do something like:
> ```
> function MyPromise(executor) {
>   var self = Reflect.construct(Promise, [executor], MyPromise); // <-- THIS
>   return self;
> }
> Object.setPrototypeOf(MyPromise, Promise);
> ```
> which works for only a single level of subclassing.  That is, it allows us
> to create and instantiate MyPromise, but now nobody can subclass
> MyPromise.  That's too bad.
>
> Is there any way around this?
>   --scott
>
> ps. Use case: My `prfun` package on npm subclasses `Promise` in order to
> add all the useful utility helpers without stomping on the global `Promise`
> object.  I'd like to do so in a way which is compatible with both native
> ES6 promises (if they are available) and properly-written ES5 shims.
> ,
>
> ___
> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Merge map values

[Andrea Giammarchi]

Not sure why everyone went for the `Map` version when in JS every object is
basically the equivalent of a `Map` already :-)

```js
let m = Array.from("mainn").reduce((m,k) => ((m[k] = 1 + (m[k] | 0)), m),
{});
```

looks a win to me, if you need to check or drop chars from the string I
would probably do it once before passing that to `Array.from`

Agreed with Kevin this is rather a StackOverflow like question :-)

Best Regards


On Tue, Apr 28, 2015 at 1:19 PM, Kevin Smith  wrote:

> Another option:
>
> var map = new Map;
> Array.from("mainn")
>   .map(c => c.toLowerCase())
>   .forEach(c => map.set(c, (map.get(c) | 0) + 1));
>
> This kind of question is probably better left for StackOverflow, however.
>
> ___
> 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: Merge map values

[Andrea Giammarchi]

Now you read again the "exercise" and realize that's impossible to have as
a piutfall ... no, I just used a KISS approach for what I can tell, no
pitfalls with one single surrogate could happen by specs.

Best Regards

On Tue, Apr 28, 2015 at 1:57 PM, Axel Rauschmayer  wrote:

> With Maps, there are less pitfalls. For example: what if you want to use
> your version to count words and one of the words is `__proto__`? Most
> pitfalls can be fixed via `Object.create(null)`, but Maps are more
> straightforward for data (vs. code).
>
> But your version can be easily adapted to Maps, I like the way you use
> `reduce()`. The `|` should be a `||`.
>
> On 28 Apr 2015, at 14:31 , Andrea Giammarchi 
> wrote:
>
> Not sure why everyone went for the `Map` version when in JS every object
> is basically the equivalent of a `Map` already :-)
>
> ```js
> let m = Array.from("mainn").reduce((m,k) => ((m[k] = 1 + (m[k] | 0)), m),
> {});
> ```
>
> looks a win to me, if you need to check or drop chars from the string I
> would probably do it once before passing that to `Array.from`
>
> Agreed with Kevin this is rather a StackOverflow like question :-)
>
> Best Regards
>
>
> On Tue, Apr 28, 2015 at 1:19 PM, Kevin Smith  wrote:
>
>> Another option:
>>
>> var map = new Map;
>> Array.from("mainn")
>>   .map(c => c.toLowerCase())
>>   .forEach(c => map.set(c, (map.get(c) | 0) + 1));
>>
>> This kind of question is probably better left for StackOverflow, however.
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
> rauschma.de
>
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Merge map values

[Andrea Giammarchi]

Moreover `undefined|0` is exactly 0. The `|0` is used in asm.js because it
explicitly declares the intent.

So again, no error in there ;-)

Regards

On Tue, Apr 28, 2015 at 1:58 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> Now you read again the "exercise" and realize that's impossible to have as
> a piutfall ... no, I just used a KISS approach for what I can tell, no
> pitfalls with one single surrogate could happen by specs.
>
> Best Regards
>
> On Tue, Apr 28, 2015 at 1:57 PM, Axel Rauschmayer 
> wrote:
>
>> With Maps, there are less pitfalls. For example: what if you want to use
>> your version to count words and one of the words is `__proto__`? Most
>> pitfalls can be fixed via `Object.create(null)`, but Maps are more
>> straightforward for data (vs. code).
>>
>> But your version can be easily adapted to Maps, I like the way you use
>> `reduce()`. The `|` should be a `||`.
>>
>> On 28 Apr 2015, at 14:31 , Andrea Giammarchi 
>> wrote:
>>
>> Not sure why everyone went for the `Map` version when in JS every object
>> is basically the equivalent of a `Map` already :-)
>>
>> ```js
>> let m = Array.from("mainn").reduce((m,k) => ((m[k] = 1 + (m[k] | 0)), m),
>> {});
>> ```
>>
>> looks a win to me, if you need to check or drop chars from the string I
>> would probably do it once before passing that to `Array.from`
>>
>> Agreed with Kevin this is rather a StackOverflow like question :-)
>>
>> Best Regards
>>
>>
>> On Tue, Apr 28, 2015 at 1:19 PM, Kevin Smith 
>> wrote:
>>
>>> Another option:
>>>
>>> var map = new Map;
>>> Array.from("mainn")
>>>   .map(c => c.toLowerCase())
>>>   .forEach(c => map.set(c, (map.get(c) | 0) + 1));
>>>
>>> This kind of question is probably better left for StackOverflow, however.
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> --
>> Dr. Axel Rauschmayer
>> a...@rauschma.de
>> rauschma.de
>>
>>
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Merge map values

[Andrea Giammarchi]

Sorry Axel, I was rushing, it sounded over-rude ... so, yes, Map are better
for words, **but** in this specific case it was about all chars/surrogate
pairs, that's why I've said Objects where safe ... plus the rest, reduce
also is very handy for this exact kind of things ;-)

But yes, if it was a owrd counter, I'd use same logic with new Map passed
instead of {} and the correct .set/.get invoke

Best Regards

On Tue, Apr 28, 2015 at 2:02 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> Moreover `undefined|0` is exactly 0. The `|0` is used in asm.js because it
> explicitly declares the intent.
>
> So again, no error in there ;-)
>
> Regards
>
> On Tue, Apr 28, 2015 at 1:58 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> Now you read again the "exercise" and realize that's impossible to have
>> as a piutfall ... no, I just used a KISS approach for what I can tell, no
>> pitfalls with one single surrogate could happen by specs.
>>
>> Best Regards
>>
>> On Tue, Apr 28, 2015 at 1:57 PM, Axel Rauschmayer 
>> wrote:
>>
>>> With Maps, there are less pitfalls. For example: what if you want to use
>>> your version to count words and one of the words is `__proto__`? Most
>>> pitfalls can be fixed via `Object.create(null)`, but Maps are more
>>> straightforward for data (vs. code).
>>>
>>> But your version can be easily adapted to Maps, I like the way you use
>>> `reduce()`. The `|` should be a `||`.
>>>
>>> On 28 Apr 2015, at 14:31 , Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
>>> Not sure why everyone went for the `Map` version when in JS every object
>>> is basically the equivalent of a `Map` already :-)
>>>
>>> ```js
>>> let m = Array.from("mainn").reduce((m,k) => ((m[k] = 1 + (m[k] | 0)),
>>> m), {});
>>> ```
>>>
>>> looks a win to me, if you need to check or drop chars from the string I
>>> would probably do it once before passing that to `Array.from`
>>>
>>> Agreed with Kevin this is rather a StackOverflow like question :-)
>>>
>>> Best Regards
>>>
>>>
>>> On Tue, Apr 28, 2015 at 1:19 PM, Kevin Smith 
>>> wrote:
>>>
>>>> Another option:
>>>>
>>>> var map = new Map;
>>>> Array.from("mainn")
>>>>   .map(c => c.toLowerCase())
>>>>   .forEach(c => map.set(c, (map.get(c) | 0) + 1));
>>>>
>>>> This kind of question is probably better left for StackOverflow,
>>>> however.
>>>>
>>>> ___
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>> --
>>> Dr. Axel Rauschmayer
>>> a...@rauschma.de
>>> rauschma.de
>>>
>>>
>>>
>>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Additional Math functions

[Andrea Giammarchi]

I've actually found this limit in the past [1] mostly for string operations
and I remember it was already discussed in here.

2048 was a safe bet for all browsers I could test those days, but it'b be
very nice if any generic function, accordingly with the environment
capabilities, could expose somehow a `Function.MAX_SAFE_ARGUMENTS_LENGTH`
like property, similar to what `Number.MAX_SAFE_INTEGER` does already.

Regards

[1] 2011 post:
http://webreflection.blogspot.co.uk/2011/07/about-javascript-apply-arguments-limit.html

On Thu, Apr 30, 2015 at 1:50 AM, Caitlin Potter 
wrote:

> Just a note about the whole upper bounds on arguments thing
>
> In V8’s case (per the comment regarding io.js), the maximum arguments
> count for Function.prototype.apply/Reflect.apply/Reflect.construct
> is 0x80 (
> https://github.com/v8/v8-git-mirror/blob/81345f1a2cdceaee8c891fc7512ae671f171308e/src/macros.py#L75)
> — On a 64mb system, this ends up being close to 70mb of data which the
> engine pushes to the stack, in addition to being on the heap in the array
> itself — which is not super tiny, but a desktop machine can probably handle
> a lot more. This isn’t a “real” stack overflow, because the RangeError is
> thrown before any arguments are actually pushed to the stack — it’s just an
> upper bound on the size of the array which can be pushed. SpiderMonkey has
> a similar arbitrary upper bounds on the argument length, ARGS_LENGTH_MAX (
> https://github.com/mozilla/gecko-dev/blob/d03ee825c74355f070b14cf4325897c813373902/js/src/vm/ArgumentsObject.h#L77)
> or 0x7A120, which is a much more conservative limit. Apparently nobody has
> complained about the smaller limit, so that’s something =)
>
> I guess what this means is, people aren’t generally depending on being
> able to push zillions of arguments to the stack via fn.apply — it’s almost
> always one of two things: either a small-ish array literal, or an actual
> Arguments object, which most likely doesn’t contain zillions of arguments
> either. These limits don’t seem unreasonable, and it’s probably okay to
> figure out an appropriate limit (especially for mobile devices) that still
> makes developers happy.
>
>
> On Apr 29, 2015, at 8:28 PM, Brendan Eich  wrote:
>
> C. Scott Ananian wrote:
>
> I'm just saying: it's not safe to spread an arbitrary array into
> `arguments` unless the spec explicitly says that the number of arguments is
> limited only by heap size (not stack size) or something like that.  The ES6
> spec does not contain any such language.
>
>
> We've talked about this in past meetings. We want implementations and
> developers to cooperate and compete, to find a normative spec we can back.
> It would be silly for us to "pick a number".
>
> /be
> ___
> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Can't do push in forEach

[Andrea Giammarchi]

`$1 => a.push($1)`

fat arrow function shines mostly in these cases, not sure there's a need
for anything else.

`($1, $2, $3) => a.push($2, $3)`

Regards

On Thu, May 14, 2015 at 5:26 PM, Emanuel Allen 
wrote:

> That would be great to have an only method on Function.prototype.only
>
> It can take one to three parameters as arguments:
> -Only with using the first argument:
>
> SomeFunction.only(1);
> only allow the first argument in. It target the place holder so:
> fn.only(2) allow the two most left argument in.
>
> -Only with using the first 2 argument:
>
> SomeFunction.only(1,2);
> only allow the second argument in; the second argument target where to
> start and the first not how many to let in. So fn.only(2,3); let the third
> and fourth argument in.
>
> -Only with using all arguments placeholder:
>
> SomeFunction.only(1,2,true);
> This will denote that we start from the right and and let the second from
> last argument in
>
> The last parameter is informing if we should start left or right when
> choosing the parameters to let in. The default is false; start left to right
>
>
> Internally this could use the function's arguments object to query what to
> let in.
>
> JS4L
>
> On May 14, 2015, at 11:37 AM, Allen Wirfs-Brock 
> wrote:
>
>
> On May 14, 2015, at 8:19 AM, Emanuel Allen wrote:
>
> Oh yes that is correct since push will push in elements separated by
> commas... Still my original problem is that I can't simply do
> arr.push(arr2.push); but it doesn't matter since it'll also push the three
> parameters into the array as well.
>
>
> exactly, see http://www.wirfs-brock.com/allen/posts/166
>
>
>
> Sent from my iPhone
>
> On May 14, 2015, at 10:49 AM, Erik Arvidsson 
> wrote:
>
> Still, the callback for forEach is called with 3 arguments; value, index
> and the array.
>
> This is clearly documented in the spec and mdn and other resources.
>
> On Thu, May 14, 2015, 10:42 Garrett Smith  wrote:
>
>> On 5/14/15, Emanuel Allen  wrote:
>> > Surprise that I can't do arr1.forEeach(arr2.push);
>> >
>>
>> Check that line more carefully.
>>
>>
>> > Will throw an error.
>> >
>> > Using bind as:
>> >
>> > push = arr2.bind(push);
>>
>> Arrays don't have a bind method.
>> --
>> Garrett
>> @xkit
>> ChordCycles.com
>> garretts.github.io
>> personx.tumblr.com
>> ___
>> 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
>
>
>
> ___
> 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: Reflect.type

[Andrea Giammarchi]

FWIW, I think whatever contains "type" in modern JS should consider
`int32`, `float64`, and all TypedArrays plus it would be awesome to have a
way to define own types.

In any case, if your idea will be implemented, I think it should have named
Symbols for debugging sake.

```js
Symbol('undefined'),
Symbol('null'),
Symbol('boolean')
```

This would be at least consistent with current implementations of
`Symbol.iterator` and friends.

Best Regards




On Thu, May 14, 2015 at 5:29 PM, Alexander Jones  wrote:

> Just an idea, if it doesn't already exist somewhere.
>
> Reflect.type(x) would match the spec's Type(x) function, in that it would
> basically be a better, more convenient typeof, i.e.
>
> Reflect.types = {
> undefined: Symbol(),
> null: Symbol(),
> boolean: Symbol(),
> string: Symbol(),
> symbol: Symbol(),
> number: Symbol(),
> object: Symbol(),
> }
>
> Reflect.type(null) === Reflect.types.null
> Reflect.type(function() {}) === Reflect.types.object
>
> We weren't able to fix typeof null in harmony, but this seems like a good
> opportunity to introduce something new. Haven't thought about the
> repercussions of future support for new value types...
>
> Any thoughts?
>
> ___
> 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: Can't do push in forEach

[Andrea Giammarchi]

> So this style I favorite since I want to avoid creating another function:

this is like believing that `fn.bind()` won't create a different
object/function ... right?

Or you want to lock that function to receive one forever until you unlock
it? That's the only way you could mutate the function behavior without
creating a new object/function like bind would do.

And since bind is at least 3X slower than fat arrow, why would you do that?


On Thu, May 14, 2015 at 7:36 PM, Emanuel Allen 
wrote:

> It should allow for:
>
> arr.forEach(arr.push.only(1));//only return a function limiting the number
> of arguments pass to it...
>
> But I guess this work too:
> arr.forEach(e=>arr.push(e));
>
> But my goal was to just:
> arr.forEach(arr.push);//will not work
>
> So this style I favorite since I want to avoid creating another function:
> arr.forEach(arr.push.only(1));
>
> Even know only will return another function base on the parameter to you
> pass to it.
>
> Still, I think it would be a great addition to the Function.prototype
> object.
>
> JS4L
>
> On May 14, 2015, at 1:42 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
> `$1 => a.push($1)`
>
> fat arrow function shines mostly in these cases, not sure there's a need
> for anything else.
>
> `($1, $2, $3) => a.push($2, $3)`
>
> Regards
>
> On Thu, May 14, 2015 at 5:26 PM, Emanuel Allen 
> wrote:
>
>> That would be great to have an only method on Function.prototype.only
>>
>> It can take one to three parameters as arguments:
>> -Only with using the first argument:
>>
>> SomeFunction.only(1);
>> only allow the first argument in. It target the place holder so:
>> fn.only(2) allow the two most left argument in.
>>
>> -Only with using the first 2 argument:
>>
>> SomeFunction.only(1,2);
>> only allow the second argument in; the second argument target where to
>> start and the first not how many to let in. So fn.only(2,3); let the third
>> and fourth argument in.
>>
>> -Only with using all arguments placeholder:
>>
>> SomeFunction.only(1,2,true);
>> This will denote that we start from the right and and let the second from
>> last argument in
>>
>> The last parameter is informing if we should start left or right when
>> choosing the parameters to let in. The default is false; start left to right
>>
>>
>> Internally this could use the function's arguments object to query what
>> to let in.
>>
>> JS4L
>>
>> On May 14, 2015, at 11:37 AM, Allen Wirfs-Brock 
>> wrote:
>>
>>
>> On May 14, 2015, at 8:19 AM, Emanuel Allen wrote:
>>
>> Oh yes that is correct since push will push in elements separated by
>> commas... Still my original problem is that I can't simply do
>> arr.push(arr2.push); but it doesn't matter since it'll also push the three
>> parameters into the array as well.
>>
>>
>> exactly, see http://www.wirfs-brock.com/allen/posts/166
>>
>>
>>
>> Sent from my iPhone
>>
>> On May 14, 2015, at 10:49 AM, Erik Arvidsson 
>> wrote:
>>
>> Still, the callback for forEach is called with 3 arguments; value, index
>> and the array.
>>
>> This is clearly documented in the spec and mdn and other resources.
>>
>> On Thu, May 14, 2015, 10:42 Garrett Smith  wrote:
>>
>>> On 5/14/15, Emanuel Allen  wrote:
>>> > Surprise that I can't do arr1.forEeach(arr2.push);
>>> >
>>>
>>> Check that line more carefully.
>>>
>>>
>>> > Will throw an error.
>>> >
>>> > Using bind as:
>>> >
>>> > push = arr2.bind(push);
>>>
>>> Arrays don't have a bind method.
>>> --
>>> Garrett
>>> @xkit
>>> ChordCycles.com
>>> garretts.github.io
>>> personx.tumblr.com
>>> ___
>>> 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
>>
>>
>>
>> ___
>> 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: let function

[Andrea Giammarchi]

I guess 'cause that cannot be scoped, let's say in a for loop ... but yeah,
I think that's not the most needed thing in the language right now, yet
another shortcut with double reserved words one after the other

Regards

On Thu, May 14, 2015 at 7:45 PM, Kevin Smith  wrote:

> Why not use a function declaration instead?
>
> On Thu, May 14, 2015 at 2:37 PM Alexander Jones  wrote:
>
>> Propose adding support for
>>
>> let function foo() {};
>>
>> which would have the equivalence of:
>>
>> let foo = function foo() {};
>>
>> The idea is to support the normal scoping of let, but without forcing you
>> to repeat yourself when naming the function, whilst still having the
>> function's name property be set.
>>
>> This would trivially extend to const and var. Also, possibly class.
>>
>> Thanks
>>
>> ___
>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Can't do push in forEach

[Andrea Giammarchi]

> (like a certain gender group would)

what is this ?

Anyway, you had your answers, I guess.

Take care

On Thu, May 14, 2015 at 8:11 PM, Emanuel Allen 
wrote:

> > So this style I favorite since I want to avoid creating another function:
>
> this is like believing that `fn.bind()` won't create a different
> object/function ... right?
>
> I like how you pick out my word (like a certain gender group would) even
> know I re correct my self right after that with:
>
> Even know only will return another function base on the parameter to you
>> pass to it.
>>
> Sent from my iPhone
>
> On May 14, 2015, at 2:50 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
> > So this style I favorite since I want to avoid creating another
> function:
>
> this is like believing that `fn.bind()` won't create a different
> object/function ... right?
>
> Or you want to lock that function to receive one forever until you unlock
> it? That's the only way you could mutate the function behavior without
> creating a new object/function like bind would do.
>
> And since bind is at least 3X slower than fat arrow, why would you do that?
>
>
> On Thu, May 14, 2015 at 7:36 PM, Emanuel Allen 
> wrote:
>
>> It should allow for:
>>
>> arr.forEach(arr.push.only(1));//only return a function limiting the
>> number of arguments pass to it...
>>
>> But I guess this work too:
>> arr.forEach(e=>arr.push(e));
>>
>> But my goal was to just:
>> arr.forEach(arr.push);//will not work
>>
>> So this style I favorite since I want to avoid creating another function:
>> arr.forEach(arr.push.only(1));
>>
>> Even know only will return another function base on the parameter to you
>> pass to it.
>>
>> Still, I think it would be a great addition to the Function.prototype
>> object.
>>
>> JS4L
>>
>> On May 14, 2015, at 1:42 PM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>> `$1 => a.push($1)`
>>
>> fat arrow function shines mostly in these cases, not sure there's a need
>> for anything else.
>>
>> `($1, $2, $3) => a.push($2, $3)`
>>
>> Regards
>>
>> On Thu, May 14, 2015 at 5:26 PM, Emanuel Allen 
>> wrote:
>>
>>> That would be great to have an only method on Function.prototype.only
>>>
>>> It can take one to three parameters as arguments:
>>> -Only with using the first argument:
>>>
>>> SomeFunction.only(1);
>>> only allow the first argument in. It target the place holder so:
>>> fn.only(2) allow the two most left argument in.
>>>
>>> -Only with using the first 2 argument:
>>>
>>> SomeFunction.only(1,2);
>>> only allow the second argument in; the second argument target where to
>>> start and the first not how many to let in. So fn.only(2,3); let the third
>>> and fourth argument in.
>>>
>>> -Only with using all arguments placeholder:
>>>
>>> SomeFunction.only(1,2,true);
>>> This will denote that we start from the right and and let the second
>>> from last argument in
>>>
>>> The last parameter is informing if we should start left or right when
>>> choosing the parameters to let in. The default is false; start left to right
>>>
>>>
>>> Internally this could use the function's arguments object to query what
>>> to let in.
>>>
>>> JS4L
>>>
>>> On May 14, 2015, at 11:37 AM, Allen Wirfs-Brock 
>>> wrote:
>>>
>>>
>>> On May 14, 2015, at 8:19 AM, Emanuel Allen wrote:
>>>
>>> Oh yes that is correct since push will push in elements separated by
>>> commas... Still my original problem is that I can't simply do
>>> arr.push(arr2.push); but it doesn't matter since it'll also push the three
>>> parameters into the array as well.
>>>
>>>
>>> exactly, see http://www.wirfs-brock.com/allen/posts/166
>>>
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On May 14, 2015, at 10:49 AM, Erik Arvidsson 
>>> wrote:
>>>
>>> Still, the callback for forEach is called with 3 arguments; value, index
>>> and the array.
>>>
>>> This is clearly documented in the spec and mdn and other resources.
>>>
>>> On Thu, May 14, 2015, 10:42 Garrett Smith 
>>> wrote:
>>>
>>>> On 5/14/15, Emanuel Allen  wrote:
>>>> > Surprise that I can&#

Re: let function

[Andrea Giammarchi]

not, in fact, in a backward compatible way, unless transpiled.

On Thu, May 14, 2015 at 8:00 PM, Domenic Denicola  wrote:

>  They can, in fact, be scoped in a for loop.
>
>
>
> *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf Of 
> *Andrea
> Giammarchi
> *Sent:* Thursday, May 14, 2015 14:53
> *To:* Kevin Smith
> *Cc:* es-discuss@mozilla.org
> *Subject:* Re: let function
>
>
>
> I guess 'cause that cannot be scoped, let's say in a for loop ... but
> yeah, I think that's not the most needed thing in the language right now,
> yet another shortcut with double reserved words one after the other
>
>
>
> Regards
>
>
>
> On Thu, May 14, 2015 at 7:45 PM, Kevin Smith  wrote:
>
>  Why not use a function declaration instead?
>
>
>
> On Thu, May 14, 2015 at 2:37 PM Alexander Jones  wrote:
>
>  Propose adding support for
>
>
>
> let function foo() {};
>
>
>
> which would have the equivalence of:
>
>
>
> let foo = function foo() {};
>
>
>
> The idea is to support the normal scoping of let, but without forcing you
> to repeat yourself when naming the function, whilst still having the
> function's name property be set.
>
>
>
> This would trivially extend to const and var. Also, possibly class.
>
>
>
> Thanks
>
>
>
> ___
> 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
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: let function

[Andrea Giammarchi]

like I've replied to Domenic, you need to transpile if you want function
declaration block-scoped backward compatible and all other ES6 goodies.

babeljs would be my pick:
https://babeljs.io

Best Regards

On Thu, May 14, 2015 at 8:40 PM, Alexander Jones  wrote:

> Ah, thanks for explaining! What about the Temporal Dead Zone of let,
> or const binding semantics, for those of us who are obsessive enough to
> desire that kind of thing everywhere?
>
> On Thursday, May 14, 2015, Bergi  wrote:
>
>> Alexander Jones schrieb:
>> > On Thursday, May 14, 2015, Domenic Denicola  wrote:
>> >
>> >>   They can, in fact, be scoped in a for loop.
>> >
>>
>>> That's not what I see, in strict mode at least, which I assume most
>>> people
>>> consider de facto by now!
>>>
>>> From V8:
>>>
>>>  SyntaxError: In strict mode code, functions can only be declared at
>>> top
>>> level or immediately within another function.
>>>
>>
>> That's ES5. In ES6, function declarations are allowed in blocks - with
>> the new block scope semantics. This was only possible as ES5 strict mode
>> held that spot open so now it doesn't break anything :-)
>> Yes, it will need a while until people get accustomed to that.
>>
>>  Bergi
>> ___
>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: function.next meta-property proposal

[Andrea Giammarchi]

Alexander ES6 "is out" as it is, here the proposal is to make reachable
that argument because indeed, since about ever, in JS you can ignore
arguments, but you can also always reach them through the argument object.

When it comes to generators, arguments object would be a misleading place
to give you any sent value 'cause that's rather how you initialize the
generator, hence the function.nect proposal, and I must say I like it in
all its weird glory.

Like you said, Python throws, meaning devs coming from Python won't ever
make such mistake of sending values a tthe very first `.next` invoke, so JS
early adopters know thanks to all bounce of early articles regarding the
early specs :D

My only concern, is that the "famous" Promise based generator wrap
https://www.promisejs.org/generators/#both needs an update:

```js
function async(makeGenerator){
  return function (value) { // <= here
var generator = makeGenerator.apply(this, arguments);

function handle(result){
  // result => { done: [Boolean], value: [Object] }
  if (result.done) return Promise.resolve(result.value);

  return Promise.resolve(result.value).then(function (res){
return handle(generator.next(res));
  }, function (err){
return handle(generator.throw(err));
  });
}

try {
  return handle(generator.next(value)); // <= here
} catch (ex) {
  return Promise.reject(ex);
}
  }
}
```

Best Regards


On Thu, May 14, 2015 at 11:25 PM, Alexander Jones  wrote:

> I don't think that's a good enough reason by itself to make this
> observable. You can pass arbitrary numbers of arguments to any function in
> JS, and they are generally ignored.
>
> On Thursday, 14 May 2015, Kevin Smith  wrote:
>
>> Alexander, ES6 generators accept any arbitrary values for the first
>> invocation of "next".  That's not going to change.
>>
>> On Thu, May 14, 2015 at 3:49 PM Alexander Jones  wrote:
>>
>>> In Python, sending a value other than `None` into the first invocation
>>> of `send` raises an error. That seems like a reasonable behaviour to me,
>>> without introducing too much weirdness.
>>>
>>> TypeError: can't send non-None value to a just-started generator
>>>
>>> On Thursday, May 14, 2015, Allen Wirfs-Brock 
>>> wrote:
>>>
 At the March TC39 meeting we agreed that the `function.next` metapropty
 should be made into a standalone stage 1 proposal.

 That proposal is now available at:
 https://github.com/allenwb/ESideas/blob/master/Generator%20metaproperty.md


 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: function.next meta-property proposal

[Andrea Giammarchi]

actually, that won't work ... so yeah, that pattern is somehow compromise,
arguments is used to indeed initialize the generator, no way to put first
value in ... oh well

On Thu, May 14, 2015 at 11:44 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> Alexander ES6 "is out" as it is, here the proposal is to make reachable
> that argument because indeed, since about ever, in JS you can ignore
> arguments, but you can also always reach them through the argument object.
>
> When it comes to generators, arguments object would be a misleading place
> to give you any sent value 'cause that's rather how you initialize the
> generator, hence the function.nect proposal, and I must say I like it in
> all its weird glory.
>
> Like you said, Python throws, meaning devs coming from Python won't ever
> make such mistake of sending values a tthe very first `.next` invoke, so JS
> early adopters know thanks to all bounce of early articles regarding the
> early specs :D
>
> My only concern, is that the "famous" Promise based generator wrap
> https://www.promisejs.org/generators/#both needs an update:
>
> ```js
> function async(makeGenerator){
>   return function (value) { // <= here
> var generator = makeGenerator.apply(this, arguments);
>
> function handle(result){
>   // result => { done: [Boolean], value: [Object] }
>   if (result.done) return Promise.resolve(result.value);
>
>   return Promise.resolve(result.value).then(function (res){
> return handle(generator.next(res));
>   }, function (err){
> return handle(generator.throw(err));
>   });
> }
>
> try {
>   return handle(generator.next(value)); // <= here
> } catch (ex) {
>   return Promise.reject(ex);
> }
>   }
> }
> ```
>
> Best Regards
>
>
> On Thu, May 14, 2015 at 11:25 PM, Alexander Jones  wrote:
>
>> I don't think that's a good enough reason by itself to make this
>> observable. You can pass arbitrary numbers of arguments to any function in
>> JS, and they are generally ignored.
>>
>> On Thursday, 14 May 2015, Kevin Smith  wrote:
>>
>>> Alexander, ES6 generators accept any arbitrary values for the first
>>> invocation of "next".  That's not going to change.
>>>
>>> On Thu, May 14, 2015 at 3:49 PM Alexander Jones  wrote:
>>>
>>>> In Python, sending a value other than `None` into the first invocation
>>>> of `send` raises an error. That seems like a reasonable behaviour to me,
>>>> without introducing too much weirdness.
>>>>
>>>> TypeError: can't send non-None value to a just-started generator
>>>>
>>>> On Thursday, May 14, 2015, Allen Wirfs-Brock 
>>>> wrote:
>>>>
>>>>> At the March TC39 meeting we agreed that the `function.next`
>>>>> metapropty should be made into a standalone stage 1 proposal.
>>>>>
>>>>> That proposal is now available at:
>>>>> https://github.com/allenwb/ESideas/blob/master/Generator%20metaproperty.md
>>>>>
>>>>>
>>>>> 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
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss