Re: Concise Method Binding

[Bergi]

Andrea Giammarchi schrieb:

Just my thoughts, I wouldn't put any self-bound thing in the class and
rather improve that `::` proposal so that whenever you `obj::method` it
creates a uniquely bound callback so that `obj::method === obj::method`


This was considered: 
https://github.com/zenparsing/es-function-bind/issues/17 - it's quite 
unexpected that an operator would return the same result every time, and 
there are security considerations as well. Also it would be quite 
complicated to spec - how and where did you store the memoisation. Feel 
free to join the discussion!


Using the `::` operator in the class declaration itself makes sense to 
me. It conveys "this method will always be bound" very effectively, and 
you wouldn't even need special syntax to access it.

```js
class Xample {
  ::myListener(…) {…}
}
```
should desugar to
```js
class Xample {
  // a getter on the prototype
  get myListener() {
// with per-instance memoisation
return this.myListener = (…) => {
  // that returns a bound method
  …
};
  }
}
```
It might be equivalently done via a custom decorator of course:
```js
class Xample {
  @autobind
  myListener(…) {…}
}
```

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

Re: Re: Concise Method Binding

[Andrea Giammarchi]

The way it could work is similar to the following one:

```js

(function (wm){'use strict';

  // just to show the possible internal slot mechanism
  Object.prototype.boundTo = function (method) {
// since I've used this for ages now in eddy.js, just replicating
var fn = typeof method === 'function' ? method : this[method];
var bound = wm.get(this);
if (!bound) wm.set(this, bound = {fn:[], bound:[]});
var i = bound.fn.indexOf(fn);
if (i < 0) bound.bound[i = bound.fn.push(fn) - 1] = fn.bind(this);
return bound.bound[i];
  };

}(new WeakMap));


// example
var obj = {method: function () { return this; }};

// now, whenever needed
obj.boundTo(obj.method);

// will create the slot and set it up with obj.method
// so that the following is true
obj.boundTo(obj.method) === obj.boundTo('method') &&
obj.boundTo('method')() === obj;

// if it's about another method
// the equivalent of this
::obj.anotherMethod

// whould be
obj.boundTo(anotherMethod);

```

The string fallback is not needed or relevant, it's just a semantic
shortcut in my example to reach the method through the object without
repeating the object name

Regards




On Wed, Nov 11, 2015 at 4:23 PM, JD Isaacks  wrote:

> Yes your point of view is more clear now, I like this is a lot.
>
> But I do not know how that would be transpiled or what the desugared
> version would look like. However, that would be awesome as you described.
>
> A thing to note. You keep using `obj::method` which is different from
> `::object.method` the former is when method is not already attached to the
> object, the later is for then it is.
>
> An example:
>
> ```
> let foo = function(){};
> let bar = {};
>
> bar::foo // foo.bind(bar);
> ```
>
> verses
>
> ```
> let bar = { foo(){} };
>
> ::foo.bar // foo.bar.bind(foo);
> ```
>
> I think both cases theoretically would be awesome to work as you
> described. Just fuzzy on how it would look underneath.
>
> On Wed, Nov 11, 2015 at 11:14 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> Yeah, I've got that, my point is that whenever you need it you just
>> `obj::method`
>>
>> Your example indeed says that currently the proposal is that
>> `obj::method` is similar to `obj.method.bind(obj)` which is indeed always
>> different and indeed you want something that makes method always the
>> same/unique bound one, which I believe is universally the preferred way.
>>
>> What are two different bound of the same method useful for? Pretty much
>> nothing, IMHO, while having a shortcut to lazily obtain a single bound
>> version of that method for that object can be useful in many ways, as
>> example `obj.on('event', anotherObj::method)` where it's always possible at
>> that point to `obj.removeListener('event', anotherObj::method)` in case its
>> needed.
>>
>> Having a shortcut that all it does is replace something already short to
>> write like a `.bind` feels to me like a missed opportunity.
>>
>> Moreover, with this improvement you won't need/care to have self-bound
>> methods at all
>>
>> ```js
>> let obj = { method(){} };
>>
>> // and whenever needed you use
>> obj::method;
>> ```
>>
>> Hope my POV is more clear now.
>>
>> Regards
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Nov 11, 2015 at 4:01 PM, JD Isaacks  wrote:
>>
>>> I think what you are suggesting already exists with `::obj.method` which
>>> evaluates to `obj.method.bind(obj)`
>>>
>>> However, this creates a new function each time so `::obj.method
>>> !== ::obj.method`, not sure how `::obj.method === ::obj.method` would work.
>>>
>>> I sort of agree with you that using it that way would be preferred.
>>> However if the community wants bound methods attached to objects, there is
>>> currently no way to do that with an object literal.
>>>
>>> You would have to do something like:
>>>
>>> ```
>>> let obj = {};
>>> obj.method = function(){}.bind(obj);
>>> ```
>>>
>>> With my proposal you can.
>>>
>>> ```
>>> let obj = { ::method(){} };
>>> ```
>>>
>>>
>>>
>>>
>>> On Wed, Nov 11, 2015 at 10:20 AM, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
 Just my thoughts, I wouldn't put any self-bound thing in the class and
 rather improve that `::` proposal so that whenever you `obj::method` it
 creates a uniquely bound callback so that `obj::method === obj::method` and
 at that point whenever you need to export, pass, or use such method you
 just `obj::method` or `obj::method()` or `let method = obj::method` and
 bring the pattern whenever it's needed instead of being slightly different
 per each "place" (class rather than objects)

 That would make it lazy, usable for events (in order to be able to also
 remove them) and easily transpilable for smoother migration.

 Having `class A { ::method() {} }` feels like somebody is playing too
 much with the protoype or "accidentally" polluting the constructor

 Regards


 On Wed, Nov 11, 

Re: Concise Method Binding

[Bergi]

Gilbert B Garza schrieb:

Forgive me if I'm missing the point, but isn't the entire purpose of using
classes to make all instances share the same function in memory via `this`
? If you want methods to always be bound, why not use closures instead?

```js
function Person (name) {
   var person = this
   person.greet = function () {
 return person.name + " says hi!";
   };
}


Yes, the point of prototypes is sharing. But maybe we don't want (cannot 
use) that.
The point of the `class` syntax is just to enable a more declarative 
definition of class methods - which should include some way to create 
instance methods as well, simply because they're needed often enough.


And being able to declare methods that will get bound outside of the 
constructor (even if that's a bit confusing) avoids much boilerplate 
again. Just compare

```js
class Person extends … {
  constructor(name) {
super(name);
this.greet = () => {
  return this.name + " says hi!";
};
  }
}
```
vs
```js
class Person extends … { // with default constructor
  ::greet() {
return this.name + " says hi!";
  }
}
```

Regards,
 Bergi

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

Re: Re: Concise Method Binding

[Gilbert B Garza]

Forgive me if I'm missing the point, but isn't the entire purpose of using
classes to make all instances share the same function in memory via `this`
? If you want methods to always be bound, why not use closures instead?

```js
function Person (name) {
  var person = this
  person.greet = function () {
return person.name + " says hi!";
  };
}

var alice = new Person('Alice');
alice.greet() //=> "Alice says hi!";

var f = alice.greet;
f() //=> "Alice says hi!";
```

On Wed, Nov 11, 2015 at 10:59 AM, JD Isaacks  wrote:

> Ahh, good point Bergi. Thanks for brining that up.
>
> On Wed, Nov 11, 2015 at 11:55 AM, JD Isaacks  wrote:
>
>> I like this very much. I would prefer this to my recommendation. So how
>> to we go about proposing it as a change to an existing proposal?
>>
>> On Wed, Nov 11, 2015 at 11:45 AM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> The way it could work is similar to the following one:
>>>
>>> ```js
>>>
>>> (function (wm){'use strict';
>>>
>>>   // just to show the possible internal slot mechanism
>>>   Object.prototype.boundTo = function (method) {
>>> // since I've used this for ages now in eddy.js, just replicating
>>> var fn = typeof method === 'function' ? method : this[method];
>>> var bound = wm.get(this);
>>> if (!bound) wm.set(this, bound = {fn:[], bound:[]});
>>> var i = bound.fn.indexOf(fn);
>>> if (i < 0) bound.bound[i = bound.fn.push(fn) - 1] = fn.bind(this);
>>> return bound.bound[i];
>>>   };
>>>
>>> }(new WeakMap));
>>>
>>>
>>> // example
>>> var obj = {method: function () { return this; }};
>>>
>>> // now, whenever needed
>>> obj.boundTo(obj.method);
>>>
>>> // will create the slot and set it up with obj.method
>>> // so that the following is true
>>> obj.boundTo(obj.method) === obj.boundTo('method') &&
>>> obj.boundTo('method')() === obj;
>>>
>>> // if it's about another method
>>> // the equivalent of this
>>> ::obj.anotherMethod
>>>
>>> // whould be
>>> obj.boundTo(anotherMethod);
>>>
>>> ```
>>>
>>> The string fallback is not needed or relevant, it's just a semantic
>>> shortcut in my example to reach the method through the object without
>>> repeating the object name
>>>
>>> Regards
>>>
>>>
>>>
>>>
>>> On Wed, Nov 11, 2015 at 4:23 PM, JD Isaacks  wrote:
>>>
 Yes your point of view is more clear now, I like this is a lot.

 But I do not know how that would be transpiled or what the desugared
 version would look like. However, that would be awesome as you described.

 A thing to note. You keep using `obj::method` which is different from
 `::object.method` the former is when method is not already attached to the
 object, the later is for then it is.

 An example:

 ```
 let foo = function(){};
 let bar = {};

 bar::foo // foo.bind(bar);
 ```

 verses

 ```
 let bar = { foo(){} };

 ::foo.bar // foo.bar.bind(foo);
 ```

 I think both cases theoretically would be awesome to work as you
 described. Just fuzzy on how it would look underneath.

 On Wed, Nov 11, 2015 at 11:14 AM, Andrea Giammarchi <
 andrea.giammar...@gmail.com> wrote:

> Yeah, I've got that, my point is that whenever you need it you just
> `obj::method`
>
> Your example indeed says that currently the proposal is that
> `obj::method` is similar to `obj.method.bind(obj)` which is indeed always
> different and indeed you want something that makes method always the
> same/unique bound one, which I believe is universally the preferred way.
>
> What are two different bound of the same method useful for? Pretty
> much nothing, IMHO, while having a shortcut to lazily obtain a single 
> bound
> version of that method for that object can be useful in many ways, as
> example `obj.on('event', anotherObj::method)` where it's always possible 
> at
> that point to `obj.removeListener('event', anotherObj::method)` in case 
> its
> needed.
>
> Having a shortcut that all it does is replace something already short
> to write like a `.bind` feels to me like a missed opportunity.
>
> Moreover, with this improvement you won't need/care to have self-bound
> methods at all
>
> ```js
> let obj = { method(){} };
>
> // and whenever needed you use
> obj::method;
> ```
>
> Hope my POV is more clear now.
>
> Regards
>
>
>
>
>
>
>
>
>
> On Wed, Nov 11, 2015 at 4:01 PM, JD Isaacks  wrote:
>
>> I think what you are suggesting already exists with `::obj.method`
>> which evaluates to `obj.method.bind(obj)`
>>
>> However, this creates a new function each time so `::obj.method
>> !== ::obj.method`, not sure how `::obj.method === ::obj.method` would 
>> work.
>>
>> I sort of agree 

Re: Re: Concise Method Binding

[Andrea Giammarchi]

Just my thoughts, I wouldn't put any self-bound thing in the class and
rather improve that `::` proposal so that whenever you `obj::method` it
creates a uniquely bound callback so that `obj::method === obj::method` and
at that point whenever you need to export, pass, or use such method you
just `obj::method` or `obj::method()` or `let method = obj::method` and
bring the pattern whenever it's needed instead of being slightly different
per each "place" (class rather than objects)

That would make it lazy, usable for events (in order to be able to also
remove them) and easily transpilable for smoother migration.

Having `class A { ::method() {} }` feels like somebody is playing too much
with the protoype or "accidentally" polluting the constructor

Regards


On Wed, Nov 11, 2015 at 2:50 PM, JD Isaacks  wrote:

> Andrea, Sort of. I am talking about adding an additional place where that
> operator `::` can be used -- with concise methods.
>
> Currently they cannot be used in the way I described above but I think
> there are several reasons why it makes sense.
>
> ___
> 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: Weak Graph

[Jason Orendorff]

On Sun, Nov 8, 2015 at 4:45 AM, Jussi Kalliokoski
 wrote:
> Perhaps graph as a concept is too wide for expressing this, but it surely
> is not a linked list either. It may look like one in some cases though,
> when there's only one lineage and no branching. However that is not
> the use case here as when application state gets transformed to a view
> representation it may have various transformations applied to it, such as
> sorting, mapping or filtering.

The last sentence here doesn't seem connected to the rest. A linear
list of versions can go through a data transformation pipeline of
sorts, maps, and filters just fine.

I don't see where lineage or branching comes into any of your
examples. I can see how it could, but I think I must be missing
something here.

> On Fri, 6 Nov 2015 at 17:31 Jason Orendorff 
> wrote:
>> Then it looks a lot like a stream, in the
>> functional reactive programming sense. Let the user (in this case, the
>> renderer) buffer the diffs as needed; it knows when to reset the list.
>> And no need for fancy data structures: it could just be an Array.
>
> That misses the point, to say the least. The idea of React is that you can
> represent the UI as a declarative function of a snapshot of the state, so
> the view doesn't have to care about async. With FRP you
> subscribe/unsubscribe to asynchronous streams which, not unlike the idea
> here, can be transformed just like normal data structures and forked (to
> fork an immutable data structure is to just pass the reference). The
> difference is that streams are an inherently async structure, [...]

FRP is not inherently async. As a programming model, I'd say it's
inherently about user code not having to care about time.

Anyway, my point here is not "you should drop what you're doing and do
FRP instead" but rather "if FRP can handle this without new GC
primitives, maybe you can too".

> while what I'm
> trying to do is not. The idea being not only that the easy case of insert
> without transforms is O(1), but almost every use case can be further better
> optimized by knowing the previous state of the data structure.

Right, the state is a left fold over a series of events. Like in FRP.

> You can implement this with streams, but that will just be an unnecessary
> abstraction level offering no simplification whatsoever while making the
> concept needlessly async.

I dunno, you sort of lost me I guess. Streams come to mind because of
what you're doing: taking a series of events, transforming them, then
applying them one by one, as they arrive, to a mutable data sink.

> Another significant difference between this and
> FRP is that streams require imperative subscribe / unsubscribe, which is
> basically just sophisticated reference counting, while having the same
> issues (user after free -> update after unmount, leaks).

This is true, and I think it's your strongest point. Furthermore in
support of your side here, even without WeakGraph, I think leaks in
FRP are more wasteful than they would be in your model, because in FRP
the "deltas" are pushed through the system until somebody turns them
off, rather than pulled on demand.

Three alternative models:

1.  In Elm, the data flow graph is static. The system manages
subscriptions. Drawback: the user can't mutate the graph procedurally.

2.  A system could allow the data flow graph to change, not
*procedurally* exactly, but when a diff is applied that changes the
UI. Since the system knows about diffs, it could then automatically
manage subscriptions based on what's actually in the UI. Subscribe on
insert, unsubscribe on delete. No manual subscription management for
the end user; within the framework, you can use reference counting
etc.

3.  Implement your system using a "WeakGraph"-like object that keeps
strong references to all revisions in a fixed-sized window of recent
history. Periodically clear old patches and revisions from this cache.
Instead of `getLineage(a, b)`, we have a method `diff(a, b)` that
typically does exactly the same thing, returning an array of patches.
But `diff` may find that the user is trying to diff two versions that
are not both in the history. Then it simply does a full diff of the
two states, effectively generating a fake lineage. Note that the
performance is not *amortized* constant time: `diff()` is *always*
fast except when diffing something quite old, which shouldn't happen.
And the memory usage of the differ is more predictable than
"WeakGraph". Drawback: fake lineages. But so what?

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

Re: Re: Concise Method Binding

[Andrea Giammarchi]

Yeah, I've got that, my point is that whenever you need it you just
`obj::method`

Your example indeed says that currently the proposal is that `obj::method`
is similar to `obj.method.bind(obj)` which is indeed always different and
indeed you want something that makes method always the same/unique bound
one, which I believe is universally the preferred way.

What are two different bound of the same method useful for? Pretty much
nothing, IMHO, while having a shortcut to lazily obtain a single bound
version of that method for that object can be useful in many ways, as
example `obj.on('event', anotherObj::method)` where it's always possible at
that point to `obj.removeListener('event', anotherObj::method)` in case its
needed.

Having a shortcut that all it does is replace something already short to
write like a `.bind` feels to me like a missed opportunity.

Moreover, with this improvement you won't need/care to have self-bound
methods at all

```js
let obj = { method(){} };

// and whenever needed you use
obj::method;
```

Hope my POV is more clear now.

Regards









On Wed, Nov 11, 2015 at 4:01 PM, JD Isaacks  wrote:

> I think what you are suggesting already exists with `::obj.method` which
> evaluates to `obj.method.bind(obj)`
>
> However, this creates a new function each time so `::obj.method
> !== ::obj.method`, not sure how `::obj.method === ::obj.method` would work.
>
> I sort of agree with you that using it that way would be preferred.
> However if the community wants bound methods attached to objects, there is
> currently no way to do that with an object literal.
>
> You would have to do something like:
>
> ```
> let obj = {};
> obj.method = function(){}.bind(obj);
> ```
>
> With my proposal you can.
>
> ```
> let obj = { ::method(){} };
> ```
>
>
>
>
> On Wed, Nov 11, 2015 at 10:20 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> Just my thoughts, I wouldn't put any self-bound thing in the class and
>> rather improve that `::` proposal so that whenever you `obj::method` it
>> creates a uniquely bound callback so that `obj::method === obj::method` and
>> at that point whenever you need to export, pass, or use such method you
>> just `obj::method` or `obj::method()` or `let method = obj::method` and
>> bring the pattern whenever it's needed instead of being slightly different
>> per each "place" (class rather than objects)
>>
>> That would make it lazy, usable for events (in order to be able to also
>> remove them) and easily transpilable for smoother migration.
>>
>> Having `class A { ::method() {} }` feels like somebody is playing too
>> much with the protoype or "accidentally" polluting the constructor
>>
>> Regards
>>
>>
>> On Wed, Nov 11, 2015 at 2:50 PM, JD Isaacks  wrote:
>>
>>> Andrea, Sort of. I am talking about adding an additional place where
>>> that operator `::` can be used -- with concise methods.
>>>
>>> Currently they cannot be used in the way I described above but I think
>>> there are several reasons why it makes sense.
>>>
>>> ___
>>> 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: Re: Concise Method Binding

[JD Isaacks]

Pardon, I meant:

```
let bar = { foo(){} };

::bar.foo // bar.foo.bind(bar);
```
in my last example.


On Wed, Nov 11, 2015 at 11:23 AM, JD Isaacks  wrote:

> Yes your point of view is more clear now, I like this is a lot.
>
> But I do not know how that would be transpiled or what the desugared
> version would look like. However, that would be awesome as you described.
>
> A thing to note. You keep using `obj::method` which is different from
> `::object.method` the former is when method is not already attached to the
> object, the later is for then it is.
>
> An example:
>
> ```
> let foo = function(){};
> let bar = {};
>
> bar::foo // foo.bind(bar);
> ```
>
> verses
>
> ```
> let bar = { foo(){} };
>
> ::foo.bar // foo.bar.bind(foo);
> ```
>
> I think both cases theoretically would be awesome to work as you
> described. Just fuzzy on how it would look underneath.
>
> On Wed, Nov 11, 2015 at 11:14 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> Yeah, I've got that, my point is that whenever you need it you just
>> `obj::method`
>>
>> Your example indeed says that currently the proposal is that
>> `obj::method` is similar to `obj.method.bind(obj)` which is indeed always
>> different and indeed you want something that makes method always the
>> same/unique bound one, which I believe is universally the preferred way.
>>
>> What are two different bound of the same method useful for? Pretty much
>> nothing, IMHO, while having a shortcut to lazily obtain a single bound
>> version of that method for that object can be useful in many ways, as
>> example `obj.on('event', anotherObj::method)` where it's always possible at
>> that point to `obj.removeListener('event', anotherObj::method)` in case its
>> needed.
>>
>> Having a shortcut that all it does is replace something already short to
>> write like a `.bind` feels to me like a missed opportunity.
>>
>> Moreover, with this improvement you won't need/care to have self-bound
>> methods at all
>>
>> ```js
>> let obj = { method(){} };
>>
>> // and whenever needed you use
>> obj::method;
>> ```
>>
>> Hope my POV is more clear now.
>>
>> Regards
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Nov 11, 2015 at 4:01 PM, JD Isaacks  wrote:
>>
>>> I think what you are suggesting already exists with `::obj.method` which
>>> evaluates to `obj.method.bind(obj)`
>>>
>>> However, this creates a new function each time so `::obj.method
>>> !== ::obj.method`, not sure how `::obj.method === ::obj.method` would work.
>>>
>>> I sort of agree with you that using it that way would be preferred.
>>> However if the community wants bound methods attached to objects, there is
>>> currently no way to do that with an object literal.
>>>
>>> You would have to do something like:
>>>
>>> ```
>>> let obj = {};
>>> obj.method = function(){}.bind(obj);
>>> ```
>>>
>>> With my proposal you can.
>>>
>>> ```
>>> let obj = { ::method(){} };
>>> ```
>>>
>>>
>>>
>>>
>>> On Wed, Nov 11, 2015 at 10:20 AM, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
 Just my thoughts, I wouldn't put any self-bound thing in the class and
 rather improve that `::` proposal so that whenever you `obj::method` it
 creates a uniquely bound callback so that `obj::method === obj::method` and
 at that point whenever you need to export, pass, or use such method you
 just `obj::method` or `obj::method()` or `let method = obj::method` and
 bring the pattern whenever it's needed instead of being slightly different
 per each "place" (class rather than objects)

 That would make it lazy, usable for events (in order to be able to also
 remove them) and easily transpilable for smoother migration.

 Having `class A { ::method() {} }` feels like somebody is playing too
 much with the protoype or "accidentally" polluting the constructor

 Regards


 On Wed, Nov 11, 2015 at 2:50 PM, JD Isaacks  wrote:

> Andrea, Sort of. I am talking about adding an additional place where
> that operator `::` can be used -- with concise methods.
>
> Currently they cannot be used in the way I described above but I think
> there are several reasons why it makes sense.
>
> ___
> 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: Is \u006eew a valid Identifier?

[Caitlin Potter]

Per spec, it’s not a keyword

> On Nov 11, 2015, at 2:50 AM, Eric Suen  wrote:
> 
> In Spec it's clear that escaped reservedWords is not Identifier nor 
> ReservedWord
> 
> In 
> https://esdiscuss.org/topic/fw-unicode-escape-sequences-for-keywords-what-s-the-correct-behaviour
>  
> 
> you said it's keywords...
> I said in Jave/C# escaped keywords is keywords, you said JavaScript is
> not Java nor C#...
> 
> In https://code.google.com/p/google-caja/wiki/SecurityAdvisory20131121 
> 
> "JavaScript parsers differ on whether they interpret escaped sequences
> of letters spelling a reserved word, such as "de\u006Cete", as an
> identifier or a reserved word." that may cause issue.
> 
> Till today still none Engine/Tool parse it correctly, Chrome/babel
> treat it as Identifier, IE 11 and Firefox 42.0 and esprima treat it as
> keywords.
> 
> It's confirm that escaped reservedWords is not Identifier. Can I have
> a final conclusion is it keywords or not?
> 
> On Tue, Nov 10, 2015 at 1:05 AM, Allen Wirfs-Brock
> > wrote:
>> 
>> On Nov 9, 2015, at 6:55 AM, Andreas Rossberg  wrote:
>> 
>> Allen, what was the motivation for allowing random escapes in
>> identifiers but not in keywords? AFAICS, it would be simpler and more
>> consistent to allow them anywhere and render "escape normalisation" a
>> uniform prepass before tokenisation. IIUC, that's what other languages
>> do. The current ES rules are far from ideal, and require jumping
>> through extra hoops, in particular, to handle context-dependent
>> keywords like `yield`.
>> 
>> /Andreas
>> 
>> 
>> see:
>> 
>> Here are some references:
>> https://github.com/tc39/tc39-notes/blob/master/es6/2013-11/nov-20.md#42-clarification-of-the-interaction-of-unicode-escapes-and-identification-syntax
>> https://bugs.ecmascript.org/show_bug.cgi?id=277
>> https://esdiscuss.org/topic/fw-unicode-escape-sequences-for-keywords-what-s-the-correct-behaviour
>> https://esdiscuss.org/topic/this-vs-thi-u0073
>> 
>> there are many others, and also there were earlier TC39 meeting discussions
>> that I didn’t find in my quick search.
>> 
>> It’s a usability vs. implementor convience trade-off.  the TC39 was to go
>> with usability (and in particular readability).
>> 
>> (Also, my recollection is that in some TC39 discussions (that I didn’t find
>> in my search) there were security concerns raised WRT allowing unicode
>> escapes in keywords. Probably concerns about code injection filters not
>> recognizing escaped keywords)
>> 
>> In ES6 (and I believe that Waldemar would claim in previous editions)
>> unicode escapes cannot be handled with such a prepass. Essentially, escaped
>> and non-escaped IdentifierName characters are only equated when doing
>> identifier binding or property name lookups. It’s probably a misperception
>> of the lexical grammar and static semantics that leads some implementors
>> down the path of thinking that  such a preps is reasonable.
>> 
>> Regarding `yield`, if it is written containing unicode escapes it is never a
>> contextual keyword.
>> 
>> BTW, personally I I would be just fine with never allowing unicode escapes
>> within IdentiferName. But that would be a web breaking change.
>> 
>> Allen
>> 
>> 
> 
> 
> 
> --
> 
> Spket IDE - Development Tool for RIA.
> 
> http://www.spket.com 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org 
> https://mail.mozilla.org/listinfo/es-discuss 
> 


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Concise Method Binding

[JD Isaacks]

Andrea, Sort of. I am talking about adding an additional place where that
operator `::` can be used -- with concise methods.

Currently they cannot be used in the way I described above but I think
there are several reasons why it makes sense.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Look-behind proposal in trouble

[Erik Corry]

And here's a similar playground for .Net, not by me:

http://www.regexplanet.com/advanced/dotnet/index.html

On Tue, Nov 10, 2015 at 11:08 AM, Erik Corry  wrote:

> I made a playground where you can try out regexps with lookbehind.
>
> https://dartpad.dartlang.org/8feea83c01ab767acdf1
>
> On Tue, Oct 13, 2015 at 9:24 PM, Nozomu Katoo 
> wrote:
>
>> Erik Corry wrote on Tue, 13 Oct 2015 at 11:18:48 +0200:
>> > Yes, that makes sense.
>> >
>> > This could be fixed by removing {n} loops from positive lookbehinds.
>> Or by
>> > doing the .NET-style back-references immediately.
>>
>> Personally, I am reluctant to remove any feature from the current
>> proposal intentionally for a future proposal that it is uncertain
>> whether it really comes or not. It might end up only making lookbehinds
>> of ECMAScript and ones of Perl 5 incompatible.
>>
>> >> On 10/10/2015 03:48, Erik Corry wrote:
>> >>
>> >>>
>> >>> On Sat, Oct 10, 2015 at 12:47 AM, Waldemar Horwat wrote:
>> >>>
>> >>> It's not a superset.  Captures would match differently.
>> >>>
>> >>>
>> >>> Can you elaborate?  How would they be different?
>> >>>
>> >>
>> >> If you have a capture inside a loop (controlled, say, by {n}), one of
>> the
>> >> proposals would capture the first instance, while the other proposal
>> would
>> >> capture the last instance.
>>
>> I was missing that point. I just confirmed that
>>
>>   perl -e "$a = 'abcdef'; $a =~ /(?<=.(.){2}.)./; print $1;"
>>
>> returned 'c' whereas .NET returned 'b'. Implementation based on my
>> proposal would return the same result as Perl 5.
>>
>>
>> By the way, at one point in this thread, I moved some email addresses
>> from To to Cc when sending my reply. But somehow several of them had
>> disappeared from the Cc field in the delivered email while they all
>> remain in a copy in my sent-email folder. I apologize to those who
>> received disconnected emails in this thread.
>>
>> Regards,
>>   Nozomu
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Concise Method Binding

[JD Isaacks]

So far all the comments have been regarding my first example using ES7
class properties proposal. No one has actually even mentioned the the part
I am proposing. Is my explanation just poor?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Concise Method Binding

[Andrea Giammarchi]

are you talking about this?
https://github.com/zenparsing/es-function-bind#ecmascript-function-bind-syntax

On Wed, Nov 11, 2015 at 2:10 PM, JD Isaacks  wrote:

> So far all the comments have been regarding my first example using ES7
> class properties proposal. No one has actually even mentioned the the part
> I am proposing. Is my explanation just poor?
>
> ___
> 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: Concise Method Binding

[Andrea Giammarchi]

You basically demonstrated nobody read my comment in there months ago ;-)

https://github.com/zenparsing/es-function-bind/issues/17#issuecomment-120978833


Anyway, the security concern is non  existent to me, every method of every
instance of every class can  be a communication channel, everything bound
can be a communication channel, I don't see why ::obj.someMethod would be
different and  is not explained anywhere in there.

But since nobody read that thread anymore,  I guess it's pointless to even
keep writing in there.

Best Regards






On Wed, Nov 11, 2015 at 4:52 PM, Bergi  wrote:

> Andrea Giammarchi schrieb:
>
>> Just my thoughts, I wouldn't put any self-bound thing in the class and
>> rather improve that `::` proposal so that whenever you `obj::method` it
>> creates a uniquely bound callback so that `obj::method === obj::method`
>>
>
> This was considered:
> https://github.com/zenparsing/es-function-bind/issues/17 - it's quite
> unexpected that an operator would return the same result every time, and
> there are security considerations as well. Also it would be quite
> complicated to spec - how and where did you store the memoisation. Feel
> free to join the discussion!
>
> Using the `::` operator in the class declaration itself makes sense to me.
> It conveys "this method will always be bound" very effectively, and you
> wouldn't even need special syntax to access it.
> ```js
> class Xample {
>   ::myListener(…) {…}
> }
> ```
> should desugar to
> ```js
> class Xample {
>   // a getter on the prototype
>   get myListener() {
> // with per-instance memoisation
> return this.myListener = (…) => {
>   // that returns a bound method
>   …
> };
>   }
> }
> ```
> It might be equivalently done via a custom decorator of course:
> ```js
> class Xample {
>   @autobind
>   myListener(…) {…}
> }
> ```
>
> Regards,
>  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: Concise Method Binding

[Gilbert B Garza]

Ah ok, I understand now; if you're using the `class` syntax, you want to be
able to arbitrarily and declaratively bind methods to the instance. Makes
sense.

I also prefer your suggestion to delegating this functionality to a
decorator; ideally the decorator would be built into the language.

On Wed, Nov 11, 2015 at 12:24 PM, Bergi  wrote:

> Gilbert B Garza schrieb:
>
>> Forgive me if I'm missing the point, but isn't the entire purpose of using
>> classes to make all instances share the same function in memory via `this`
>> ? If you want methods to always be bound, why not use closures instead?
>>
>> ```js
>> function Person (name) {
>>var person = this
>>person.greet = function () {
>>  return person.name + " says hi!";
>>};
>> }
>>
>
> Yes, the point of prototypes is sharing. But maybe we don't want (cannot
> use) that.
> The point of the `class` syntax is just to enable a more declarative
> definition of class methods - which should include some way to create
> instance methods as well, simply because they're needed often enough.
>
> And being able to declare methods that will get bound outside of the
> constructor (even if that's a bit confusing) avoids much boilerplate again.
> Just compare
> ```js
> class Person extends … {
>   constructor(name) {
> super(name);
> this.greet = () => {
>   return this.name + " says hi!";
> };
>   }
> }
> ```
> vs
> ```js
> class Person extends … { // with default constructor
>   ::greet() {
> return this.name + " says hi!";
>   }
> }
> ```
>
> Regards,
>  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