Re: ES6 Proxy Function Call Trap
To be honest, you could simply subclass Proxy to add an invoke hook, if
it's that simple:
```js
function makeHandler(handler) {
let {get, invoke} = handler;
let lastGet = false;
let opts = {};
Object.keys(opts)
.filter(key = key !== 'get' key !== 'call')
.map(key = [key, handler[key]])
.forEach(([key, func]) =
opts[key] = function () {
lastGet = false;
func.apply(this, arguments);
});
opts.get = function (target, property) {
new Proxy(target[property], {
apply(f, thisArg, args) {
return invoke.call(handler, target, property, args);
},
});
return get.apply(this, arguments);
};
return opts;
}
class InvokeProxy extends Proxy {
constructor(target, handler) {
super(target, makeHandler(handler));
}
static revocable(target, handler) {
return Proxy.revocable(target, makeHandler(handler));
}
```
-- Forwarded message --
From: Tom Van Cutsem tomvc...@gmail.com
To: Kevin Smith zenpars...@gmail.com
Cc: es-discuss es-discuss@mozilla.org
Date: Thu, 11 Jun 2015 21:01:48 +0200
Subject: Re: ES6 Proxy Function Call Trap
Edwin,
I sympathize with your point-of-view, but we've debated all the pros and
cons of `invoke` long ago, and unless new arguments are brought to the
table, I don't think it will be added again soon.
To clarify why the invoke = get + call equivalence is so important,
consider for instance the common coding pattern of a conditional method
call, where one only wants to invoke a method if it exists:
```js
var foo = obj.foo;
if (foo) {
foo.call(obj)
}
```
With the current Proxy API, the `get` trap returns a function (or a proxy
for a function), and the code works fine regardless of whether foo() is
called as a method, or as a function.
With the addition of `invoke`, if you don't also provide a `get` trap, then
the code will not behave as expected. Likely `obj.foo` will return
`undefined`, even though `obj.foo()` would have triggered the `invoke` trap
and done something useful.
So, *any* robust use of `invoke` still requires implementing a `get` trap
(to allow for all the use cases where methods are extracted as functions
from objects). As a result, it would lead to a net *increase* in
lines-of-code.
2015-06-11 15:48 GMT+02:00 Kevin Smith zenpars...@gmail.com:
Could a userland library make writing these kinds of proxies more
ergonomic?
I don't see why not. The Proxy API offers only the bare minimum tools to
create your own custom exotic objects. Arguably we need to grow some good
libraries around it to make building these types of objects more routine
(although I'd be the first to point out that you should avoid exotic
objects unless there's a really compelling reason to go that route)
Cheers,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Example of real world usage of function bind syntax
On Fri, Jun 12, 2015 at 8:35 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
On Thu, Jun 11, 2015 at 5:31 PM, Kevin Smith zenpars...@gmail.com wrote:
I'm not entirely sure if it's appropriate, but I just published a library
called Trine[1] that takes advantage and displays the power of the proposed
function bind syntax. Consider this my upvote for the proposal. :)
It's definitely appropriate, as long as it's clear to users that the `::`
syntax is experimental, non-standard and subject to change. This is
actually the kind of usage feedback we were hoping to get : )
Great!
Has there been any discussion of anyone championing this proposal for
ES2016? I would very much like to see it land, especially given that I've
already been using it extensively in production via Babel. :P
Not sure you should use it in production, just yet...
It's okay, it's used in a very small product and the worst that can happen
is that it will bind (heh) us to a specific version of babel until the
syntax is removed from the codebase.
I'm the champion for this proposal, and I plan on pursuing it. I'm not
sure that it will fit into the ES2016 timeline though, given the time
remaining and other priorities (like async/await). To be honest, I'm not
overly worried about which train it leaves on.
Since you brought it up...
I've been considering reducing the scope of the proposal, focusing on the
immediate apply aspect of the operator, while leaving open the option of
adding the other features at a later time. Specifically,
- Remove the prefix form of the operator.
- Restrict the syntax such that an argument list is required after the
right operand.
In other words, these forms would no longer be valid under the proposal
(although they could be re-introduced in another proposal):
let bf1 = ::obj.foo.bar;
let bf2 = obj::foo;
But this would still be OK:
obj::foo(bar);
Given your experience with the operator and your use cases, would you
still be in favor of such a minimal proposal?
I see the most benefits in the immediate invocation forms of the proposal,
and have used that more extensively than the other forms. However, working
with React, I've found that the prefix form is also very nice thing to have
for all the ::this.onClick, etc. things. So yes, I would still be in favor,
but to me the prefix form is still a pretty cool nice to have.
Looking at the discussion about partial application thought of as a
blocker for the syntax, I'd prefer to keep the two separate - for example
the proposal I made for partial application [1] is compatible with or
without the bind syntax: `foo::bar(qoo, ???)` would be the same as doing
`bar.bind(foo, qoo)`.
Forgot to mention that Trine actually implements the placeholder syntax I
proposed: parseInt::partial(_) // returns a unary version of parseInt
However, if there's even the remote possibility of getting the
non-immediate forms of the bind syntax do a light binding (i.e. always
returning the referentially same function), that would be IMO worth
blocking the non-immediate forms over to see if it could lead anywhere.
Currently as far as I understand, for example React considers all my event
listeners changed on every render and removes the listeners and adds them
again, because they're bound at render-time.
As a slight offtrack, the slim arrow function would be very handy with
this style of programming. ;) Also, one thing I noticed while writing this
library is that being able to name `this` might be interesting. Currently
even in syntax extensions such as flow, there's no natural way to type
annotate `this` in standalone functions. However, say we had a syntax like
this:
function (a, b) {
return a + b;
}
Where the `this` argument would be accessible in the a parameter, it could
be simply type annotated as
function (a : number, b : number) {
return a + b;
}
Regarding polymorphism, I don't think the bind syntax changes things much,
it just (possibly) makes polymorphism happen more at the `this` slot. Also,
I wonder if in the case of the bind operator the engines could actually
hold an inline cache in the shape of the object instead of the function
itself. I'm also uncertain if the engines currently consider things such as
function getFromUnknownType (key, value, has, get) {
if ( has(key) ) { return get(key); }
return null;
}
polymorphic or if they're able to statically verify that actually the
types in there remain the same regardless of the type of the `key` and
`value` passed in (unless the passed functions are inlined of course).
I wouldn't be *too* worried about polymorphism though, since the
advantages of the syntax allow us to add methods to iterables, which
means we can do
products
::quickSort(function (b) { return this.price - b.price; })
::head(k);
versus
products
.sort(function (a, b) { return a.price - b.price; })
.slice(0, k);
Re: RegExp.escape
I made an initial repo https://github.com/benjamingr/RexExp.escape/blob/master/README.md I've added a reference to that gist - I'll start poking around and have scheduled to meet with some local people interested in helping next week. I'll keep you updated. On Fri, Jun 12, 2015 at 9:57 PM, Juriy Zaytsev kan...@gmail.com wrote: I made this gist back in the days — https://gist.github.com/kangax/9698100 — and I believe Rick was going to bring it up at one of the meetings. I don't have time to set up repo and work with TC39 member so if you can continue carrying that torch, that would be awesome! -- kangax On Fri, Jun 12, 2015 at 2:52 PM, Benjamin Gruenaum benjami...@gmail.com wrote: You know what? Why not. I'm going to try to champion this. I talked to Domenic and he said he's willing to help me with this which is a big help (this would be my first time). I'll open a GitHub repo and see what I can come up with. ___ 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: `new Object` vs `Object` difference
I think historically `Array`, `Function`, and `Object` can be used with or without `new` and the result is exactly the same ... since, about, ever. Agreed if that's actually indeed the case, we could have just one definition for those 3 constructors (not just Object) Regards On Fri, Jun 12, 2015 at 10:19 PM, Benjamin Gruenaum benjami...@gmail.com wrote: Ok, so I gave this a few hours in the open. So, I'm looking at the ES5 specification (also checked the current ES draft which is similar) at the definition of what new Object and Object do. To my surprise: - `new Object` describes a whole algorithm of how the object constructor works - treating what happens with different kinds of values. Basically calls `ToObject` on non objects - identity on objects and builds on null and undefined. - `Object` has a special first step for null and undefined where it builds an object and then calls `ToObject` on primitives and identity on objects. After reading the description a few times - they seem identical. However, clearly from the spec they do *something* different. For example in Array - calling new Array is specified as the function call Array(…) is equivalent to the object creation expression new Array(…) with the same arguments.` The only difference I've been able to identify with the help of a friend is that the behaviour can be different on host objects. Where `Object` must return the same host object and `new Object` _may_ return the same host object. I've taken a look at the ES3 specification and it too uses the same definition so I suspect this is something that has been there for a long time. - Why are `Object` and `new Object` specified differently? - If there is no actual reason, can the definition be simplified for the next version of the spec? (I think simplifying the spec is important and possibly underrated) Sorry if I'm missing something obvious. Originally asked on Stack Overflow - http://stackoverflow.com/q/30801497/1348195 ___ 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: `new Object` vs `Object` difference
On Jun 12, 2015, at 2:47 PM, Benjamin Gruenaum wrote: That's good to know and it's good to know I'm not the first one to spot this. While we're visiting the spec on that: Why is it specified that When called as a constructor it creates a new ordinary object. When Object is called as a function rather than as a constructor, it performs a type conversion. - wouldn't it make more sense to remove that or specify behaves the same way? yes, probably Where is it actually explained what Object does when called as a constructor? It doesn't because the behavior is seem in both cases. Step 1 of http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object-value is looking for the case of a `super()` call from a subclass constructor. The difference - at least in the phrasing of Object vs Array seems to be just as present in the latest spec draft from what I can tell. Yes, the Object description still contains some ancient language that should probably be removed in the future as it adds not (except perhaps confusion) to the spec. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Language design
Hello all. I have opened the page https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/ECMAScript_6_support_in_Mozilla and was horrified. What happened with JS? Why do we need all this methods? Why a lot of functionality is now doubled, and a lot of new badly designed API and language features was introduced? I understand the word compatibility, but I think that no compatibility worth enough to be preserved sacrificing the language design making it self-contradictary. For example, Object.is compares identity. Operator === also compares identity but in a bit differrent way. Why not just make == check equality only between compatible types, === check identity (that the object is the same) and throw out Object.is. Operator [] casts its argument to string ... but not when used with Symbol (why not just allow the key to be any object and match using ===). New iterator API relyes on Symbol.iterator. Why do we need it? Why not just use strings and prototypes? fromCodePoint doubles fromCharCode, but differs a bit. Why didn't you repurpose fromCharCode, just allowing it to take a string arguments describing codepages? Iterability and enumerability are distinct, but iterability is just enumerability with numeric key (yeah, I know that it is possible to create endless or random iterator, but in fact this means that you just don't need to use the key provided). Why there is iterability, but not enumerability with properties of iterability and enumerability united? Why we need enumerability to make it work with for ... in and iterability to make it work with for ... of? Why can't we use methods definitions to define methods as a function declaration? Why JS is so badly designed?___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `new Object` vs `Object` difference
That's good to know and it's good to know I'm not the first one to spot this. While we're visiting the spec on that: Why is it specified that When called as a constructor it creates a new ordinary object. When Object is called as a function rather than as a constructor, it performs a type conversion. - wouldn't it make more sense to remove that or specify behaves the same way? Where is it actually explained what Object does when called as a constructor? The difference - at least in the phrasing of Object vs Array seems to be just as present in the latest spec draft from what I can tell. On Sat, Jun 13, 2015 at 12:38 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: ES6 eliminates the (possible) special treatment of host objects passed as the argument to the Object constructor. As far as anybody seems to know, no implementation had ever made use of that allowance. The ES6 spec. also unifies the [[Call]] and [[Constructor]] behavior of Object into a single algorithm http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object-value ES6 unifies all [[Call]] and [[Construct]] algorithms for built-in constructors in this same manner. Allen On Jun 12, 2015, at 1:19 PM, Benjamin Gruenaum wrote: Ok, so I gave this a few hours in the open. So, I'm looking at the ES5 specification (also checked the current ES draft which is similar) at the definition of what new Object and Object do. To my surprise: - `new Object` describes a whole algorithm of how the object constructor works - treating what happens with different kinds of values. Basically calls `ToObject` on non objects - identity on objects and builds on null and undefined. - `Object` has a special first step for null and undefined where it builds an object and then calls `ToObject` on primitives and identity on objects. After reading the description a few times - they seem identical. However, clearly from the spec they do *something* different. For example in Array - calling new Array is specified as the function call Array(…) is equivalent to the object creation expression new Array(…) with the same arguments.` The only difference I've been able to identify with the help of a friend is that the behaviour can be different on host objects. Where `Object` must return the same host object and `new Object` _may_ return the same host object. I've taken a look at the ES3 specification and it too uses the same definition so I suspect this is something that has been there for a long time. - Why are `Object` and `new Object` specified differently? - If there is no actual reason, can the definition be simplified for the next version of the spec? (I think simplifying the spec is important and possibly underrated) Sorry if I'm missing something obvious. Originally asked on Stack Overflow - http://stackoverflow.com/q/30801497/1348195 ___ 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: `new Object` vs `Object` difference
Thanks, Array and Function (as well as RegExp) actually directly specify that calling them with and without new produces equivalent results where `Object` doesn't and actually has a hole (in what it _may_ do to host objects). It's just baffling that `Object` is defined so differently. I wonder if there are old browsers that differ on this, or there is a bigger reason for this behaviour. On Sat, Jun 13, 2015 at 12:05 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I think historically `Array`, `Function`, and `Object` can be used with or without `new` and the result is exactly the same ... since, about, ever. Agreed if that's actually indeed the case, we could have just one definition for those 3 constructors (not just Object) Regards On Fri, Jun 12, 2015 at 10:19 PM, Benjamin Gruenaum benjami...@gmail.com wrote: Ok, so I gave this a few hours in the open. So, I'm looking at the ES5 specification (also checked the current ES draft which is similar) at the definition of what new Object and Object do. To my surprise: - `new Object` describes a whole algorithm of how the object constructor works - treating what happens with different kinds of values. Basically calls `ToObject` on non objects - identity on objects and builds on null and undefined. - `Object` has a special first step for null and undefined where it builds an object and then calls `ToObject` on primitives and identity on objects. After reading the description a few times - they seem identical. However, clearly from the spec they do *something* different. For example in Array - calling new Array is specified as the function call Array(…) is equivalent to the object creation expression new Array(…) with the same arguments.` The only difference I've been able to identify with the help of a friend is that the behaviour can be different on host objects. Where `Object` must return the same host object and `new Object` _may_ return the same host object. I've taken a look at the ES3 specification and it too uses the same definition so I suspect this is something that has been there for a long time. - Why are `Object` and `new Object` specified differently? - If there is no actual reason, can the definition be simplified for the next version of the spec? (I think simplifying the spec is important and possibly underrated) Sorry if I'm missing something obvious. Originally asked on Stack Overflow - http://stackoverflow.com/q/30801497/1348195 ___ 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: `new Object` vs `Object` difference
Yep, RegExp too, you are right. The only caveat that might comes to my mind is dealing with foreigner objects ( through plugins such Java applets and stuff ) where maybe there is a difference, but I've no memory of any sort of real-world use case based on the fact that `new` was mandatory. Indeed if you try even minifiers, you'll notice that code like this ```js this.bla = new Object(parent.foreignObject); ``` will be minified as ```js this.bla=Object(parent.foreignObject); ``` On Fri, Jun 12, 2015 at 11:09 PM, Benjamin Gruenaum benjami...@gmail.com wrote: Thanks, Array and Function (as well as RegExp) actually directly specify that calling them with and without new produces equivalent results where `Object` doesn't and actually has a hole (in what it _may_ do to host objects). It's just baffling that `Object` is defined so differently. I wonder if there are old browsers that differ on this, or there is a bigger reason for this behaviour. On Sat, Jun 13, 2015 at 12:05 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I think historically `Array`, `Function`, and `Object` can be used with or without `new` and the result is exactly the same ... since, about, ever. Agreed if that's actually indeed the case, we could have just one definition for those 3 constructors (not just Object) Regards On Fri, Jun 12, 2015 at 10:19 PM, Benjamin Gruenaum benjami...@gmail.com wrote: Ok, so I gave this a few hours in the open. So, I'm looking at the ES5 specification (also checked the current ES draft which is similar) at the definition of what new Object and Object do. To my surprise: - `new Object` describes a whole algorithm of how the object constructor works - treating what happens with different kinds of values. Basically calls `ToObject` on non objects - identity on objects and builds on null and undefined. - `Object` has a special first step for null and undefined where it builds an object and then calls `ToObject` on primitives and identity on objects. After reading the description a few times - they seem identical. However, clearly from the spec they do *something* different. For example in Array - calling new Array is specified as the function call Array(…) is equivalent to the object creation expression new Array(…) with the same arguments.` The only difference I've been able to identify with the help of a friend is that the behaviour can be different on host objects. Where `Object` must return the same host object and `new Object` _may_ return the same host object. I've taken a look at the ES3 specification and it too uses the same definition so I suspect this is something that has been there for a long time. - Why are `Object` and `new Object` specified differently? - If there is no actual reason, can the definition be simplified for the next version of the spec? (I think simplifying the spec is important and possibly underrated) Sorry if I'm missing something obvious. Originally asked on Stack Overflow - http://stackoverflow.com/q/30801497/1348195 ___ 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: `new Object` vs `Object` difference
ES6 eliminates the (possible) special treatment of host objects passed as the argument to the Object constructor. As far as anybody seems to know, no implementation had ever made use of that allowance. The ES6 spec. also unifies the [[Call]] and [[Constructor]] behavior of Object into a single algorithm http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object-value ES6 unifies all [[Call]] and [[Construct]] algorithms for built-in constructors in this same manner. Allen On Jun 12, 2015, at 1:19 PM, Benjamin Gruenaum wrote: Ok, so I gave this a few hours in the open. So, I'm looking at the ES5 specification (also checked the current ES draft which is similar) at the definition of what new Object and Object do. To my surprise: - `new Object` describes a whole algorithm of how the object constructor works - treating what happens with different kinds of values. Basically calls `ToObject` on non objects - identity on objects and builds on null and undefined. - `Object` has a special first step for null and undefined where it builds an object and then calls `ToObject` on primitives and identity on objects. After reading the description a few times - they seem identical. However, clearly from the spec they do *something* different. For example in Array - calling new Array is specified as the function call Array(…) is equivalent to the object creation expression new Array(…) with the same arguments.` The only difference I've been able to identify with the help of a friend is that the behaviour can be different on host objects. Where `Object` must return the same host object and `new Object` _may_ return the same host object. I've taken a look at the ES3 specification and it too uses the same definition so I suspect this is something that has been there for a long time. - Why are `Object` and `new Object` specified differently? - If there is no actual reason, can the definition be simplified for the next version of the spec? (I think simplifying the spec is important and possibly underrated) Sorry if I'm missing something obvious. Originally asked on Stack Overflow - http://stackoverflow.com/q/30801497/1348195 ___ 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
`new Object` vs `Object` difference
Ok, so I gave this a few hours in the open. So, I'm looking at the ES5 specification (also checked the current ES draft which is similar) at the definition of what new Object and Object do. To my surprise: - `new Object` describes a whole algorithm of how the object constructor works - treating what happens with different kinds of values. Basically calls `ToObject` on non objects - identity on objects and builds on null and undefined. - `Object` has a special first step for null and undefined where it builds an object and then calls `ToObject` on primitives and identity on objects. After reading the description a few times - they seem identical. However, clearly from the spec they do *something* different. For example in Array - calling new Array is specified as the function call Array(…) is equivalent to the object creation expression new Array(…) with the same arguments.` The only difference I've been able to identify with the help of a friend is that the behaviour can be different on host objects. Where `Object` must return the same host object and `new Object` _may_ return the same host object. I've taken a look at the ES3 specification and it too uses the same definition so I suspect this is something that has been there for a long time. - Why are `Object` and `new Object` specified differently? - If there is no actual reason, can the definition be simplified for the next version of the spec? (I think simplifying the spec is important and possibly underrated) Sorry if I'm missing something obvious. Originally asked on Stack Overflow - http://stackoverflow.com/q/30801497/1348195 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: RegExp.escape
@Alexander Jones: no new syntax is needed to implement what you want; we
already have Template Strings. For example, you could define a new
function `RegExp.join` (which takes either an array or a string as its
first argument, see below):
```
var pattern = RegExp.join`^(abc${ someString, escaped }|def${ /a reg|exp/
})$`
// apply flags?
var pattern = RegExp.join('x')` abc | def \$`;
```
`RegExp.escape()` would be used internally to handle the interpolation of
an string into the regexp. But these features are orthogonal.
--scott
On Fri, Jun 12, 2015 at 2:57 PM, Juriy Zaytsev kan...@gmail.com wrote:
I made this gist back in the days — https://gist.github.com/kangax/9698100
— and I believe Rick was going to bring it up at one of the meetings. I
don't have time to set up repo and work with TC39 member so if you can
continue carrying that torch, that would be awesome!
--
kangax
On Fri, Jun 12, 2015 at 2:52 PM, Benjamin Gruenaum benjami...@gmail.com
wrote:
You know what? Why not. I'm going to try to champion this.
I talked to Domenic and he said he's willing to help me with this which
is a big help (this would be my first time).
I'll open a GitHub repo and see what I can come up with.
___
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: RegExp.escape
You know what? Why not. I'm going to try to champion this. I talked to Domenic and he said he's willing to help me with this which is a big help (this would be my first time). I'll open a GitHub repo and see what I can come up with. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: RegExp.escape
I made this gist back in the days — https://gist.github.com/kangax/9698100 — and I believe Rick was going to bring it up at one of the meetings. I don't have time to set up repo and work with TC39 member so if you can continue carrying that torch, that would be awesome! -- kangax On Fri, Jun 12, 2015 at 2:52 PM, Benjamin Gruenaum benjami...@gmail.com wrote: You know what? Why not. I'm going to try to champion this. I talked to Domenic and he said he's willing to help me with this which is a big help (this would be my first time). I'll open a GitHub repo and see what I can come up with. ___ 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: Example of real world usage of function bind syntax
Yeah, I am. Oops. Sorry about that. On Fri, Jun 12, 2015, 13:41 Brendan Eich bren...@mozilla.org wrote: Any chance you could reply so that your messages show up in thread? Are you reading by digest mode, possibly? /be Isiah Meadows wrote: I need to be using this library! I, myself, used the syntax for virtual methods quite a bit, and personally replicated a third of your library without realizing it. Also, it's a lot easier and nicer to type `foo.map(::this.bar)` than `foo.map(this.bar.bind(this))` or `foo.map(x = this.bar(x))`. I also (ab)used it to create my own DSL for conditionals that would be equivalent to a condition-less `switch` in CoffeeScript and the like, but that was more of an experiment than anything else. -- Forwarded message -- From: Jussi Kalliokoski jussi.kallioko...@gmail.com mailto:jussi.kallioko...@gmail.com To: es-discuss es-discuss@mozilla.org mailto:es-discuss@mozilla.org Cc: Date: Thu, 11 Jun 2015 15:19:28 +0300 Subject: Example of real world usage of function bind syntax I'm not entirely sure if it's appropriate, but I just published a library called Trine[1] that takes advantage and displays the power of the proposed function bind syntax. Consider this my upvote for the proposal. :) Has there been any discussion of anyone championing this proposal for ES2016? I would very much like to see it land, especially given that I've already been using it extensively in production via Babel. :P [1] https://github.com/jussi-kalliokoski/trine ___ es-discuss mailing list es-discuss@mozilla.org mailto: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: Language design
On 6/12/15 8:21 PM, KOLANICH wrote: No. I really think that -0 === +0 also should be false, because they are different objects. So should be 0==0. I don't think it will break a lot of code Theory is great, but experiment is better. With that in mind, I have created a build of Firefox 38 that you can try that has just your proposed modification for ==: test false when one side is a string and the other is a number. Making -0 === +0 test false would take more effort than I'm willing to put in right now, since the JITs actually optimize that path, unlike the other one, and I'd have to change the actual low-level assembly used in a pretty nontrivial (e.g. ucomisd treats 0 and -0 as equal so I'd need to add manual tests for 0 vs -0). In any case, you can try this build out and report back on whether you find any problems on websites. You can download the test builds at one of the following links, depending on which one you want: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bzbar...@mozilla.com-7c95947645f5/try-linux/firefox-38.0.6.en-US.linux-i686.tar.bz2 http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bzbar...@mozilla.com-7c95947645f5/try-linux64/firefox-38.0.6.en-US.linux-x86_64.tar.bz2 http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bzbar...@mozilla.com-7c95947645f5/try-win32/firefox-38.0.6.en-US.win32.zip The Mac build is still in progress, but should appear in http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bzbar...@mozilla.com-7c95947645f5/try-macosx64/ in a few hours I expect. -Boris P.S. I've encountered at least one site in the past week that relied on string vs number == just triaging bug reports. So I'm not too hopeful about your chances of avoiding problems with this build, but I figure you should give it a shot at least. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: RegExp.escape()
Nice! Inspired
// Based on
// https://github.com/benjamingr/RexExp.escape/blob/master/polyfill.js
function re(template, ...subs) {
const parts = [];
const numSubs = subs.length;
for (let i = 0; i numSubs; i++) {
parts.push(template.raw[i]);
parts.push(subs[i].replace(/[\/\\^$*+?.()|[\]{}]/g, '\\$'));
}
parts.push(template.raw[numSubs]);
return RegExp(parts.join(''));
}
On Fri, Jun 12, 2015 at 5:48 PM, Benjamin Gruenbaum benjami...@gmail.com
wrote:
Ok, with a ton of help from Domenic I've put up
http://benjamingr.github.io/RexExp.escape/
Less cool coloring but more links and motivating examples and so on at
https://github.com/benjamingr/RexExp.escape
As this is my first attempt at this sort of thing - any non-bikeshed
feedback would be appreciated :)
___
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: `new Object` vs `Object` difference
JS is very much like writing with a pen (traditionally speaking). We can only try to make less errors as we move forward, but what’s there it’s there and it’s either too expensive or impossible to change. On Jun 13, 2015, at 7:33 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 12, 2015, at 2:47 PM, Benjamin Gruenaum wrote: That's good to know and it's good to know I'm not the first one to spot this. While we're visiting the spec on that: Why is it specified that When called as a constructor it creates a new ordinary object. When Object is called as a function rather than as a constructor, it performs a type conversion. - wouldn't it make more sense to remove that or specify behaves the same way? yes, probably Where is it actually explained what Object does when called as a constructor? It doesn't because the behavior is seem in both cases. Step 1 of http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object-value http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object-value is looking for the case of a `super()` call from a subclass constructor. The difference - at least in the phrasing of Object vs Array seems to be just as present in the latest spec draft from what I can tell. Yes, the Object description still contains some ancient language that should probably be removed in the future as it adds not (except perhaps confusion) to the spec. 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[2]: Language design
You missed that Object.is(-0, +0) (and with arguments transposed) is false,
while -0 === +0.
No. I really think that -0 === +0 also should be false, because they are
different objects. So should be 0==0. I don't think it will break a lot of
code, because I cannot mind a situation where such comparisons can be needed
(except comparing zIndex and other numeric attributes casted to strings
automatically, but it is not very hard to insert parseFloat there).
If your point is that Object.is does not pull its weight
My point is that there shouldn't not be a lot of similar API which behavior is
not intuitively clear.
I don't know what you think about it, but I think that this should have
semantics of comparison by value. We can compare numbers, so let 3.0==3 be
true. A string and a number have different semantics (string is array of
characters, number is number), so let 3==3 be false.
Also ({a:1}=={a:1}) should be true; undefined==undefined should be true;
null==null should be true;NaN== NaN should be false;
Number.POSITIVE_INVINITY==Number.POSITIVE_INVINITY should be false.
=== has identity semantics
undefined===undefined shoulld be true; null===null should be true;NaN=== NaN
should be true; Number.POSITIVE_INVINITY===Number.POSITIVE_INVINITY should be
true because they all in fact a special value.
-0==+0 should be true, because it is the same number. -0===+0 should be false
because they are different values (which in case of integer can be understood
as differrent objects of class Number).
And again, I don't think that someone strongly relies on current semantics of
comparison because of its counterintuitivity.
Behaving the described way we only need the two operators.
Пятница, 12 июня 2015, 16:45 -07:00 от Brendan Eich bren...@mozilla.org:
Edwin Reynoso wrote:
Yes please edit it, you don't have to repost. BTW the only thing I can
agree with is the `Object.is()` which to me seems like the only
problem it solves is `Object.is(NaN, NaN)` now returns true
You didn't agree with the root post (whose sender has had the mod flag
set for moderated postings, btw). That root post ignored compatibility
constraints that have been discussed to death over the years, and just
glibly asserted that == and === could be changed. So, I don't believe
you agreed with that noise. Am I mistaken?
If your point is that Object.is does not pull its weight, make a
stronger case for why people should have to write it by hand.
You missed that Object.is(-0, +0) (and with arguments transposed) is
false, while -0 === +0.
/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: Language design
Yes please edit it, you don't have to repost. BTW the only thing I can agree with is the `Object.is()` which to me seems like the only problem it solves is `Object.is(NaN, NaN)` now returns true On Fri, Jun 12, 2015 at 7:11 PM, Kevin Smith zenpars...@gmail.com wrote: https://i.imgflip.com/mtot6.jpg On Fri, Jun 12, 2015 at 6:55 PM KOLANICH kola...@mail.ru wrote: Hello all. I have opened the page https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/ECMAScript_6_support_in_Mozilla and was horrified. What happened with JS? Why do we need all this methods? Why a lot of functionality is now doubled, and a lot of new badly designed API and language features was introduced? I understand the word compatibility, but I think that no compatibility worth enough to be preserved sacrificing the language design making it self-contradictary. For example, Object.is compares identity. Operator === also compares identity but in a bit differrent way. Why not just make == check equality only between compatible types, === check identity (that the object is the same) and throw out Object.is. Operator [] casts its argument to string ... but not when used with Symbol (why not just allow the key to be any object and match using ===). New iterator API relyes on Symbol.iterator. Why do we need it? Why not just use strings and prototypes? fromCodePoint doubles fromCharCode, but differs a bit. Why didn't you repurpose fromCharCode, just allowing it to take a string arguments describing codepages? Iterability and enumerability are distinct, but iterability is just enumerability with numeric key (yeah, I know that it is possible to create endless or random iterator, but in fact this means that you just don't need to use the key provided). Why there is iterability, but not enumerability with properties of iterability and enumerability united? Why we need enumerability to make it work with for ... in and iterability to make it work with for ... of? Why can't we use methods definitions to define methods as a function declaration? Why JS is so badly designed? ___ 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: Language design
Edwin Reynoso wrote: Yes please edit it, you don't have to repost. BTW the only thing I can agree with is the `Object.is()` which to me seems like the only problem it solves is `Object.is(NaN, NaN)` now returns true You didn't agree with the root post (whose sender has had the mod flag set for moderated postings, btw). That root post ignored compatibility constraints that have been discussed to death over the years, and just glibly asserted that == and === could be changed. So, I don't believe you agreed with that noise. Am I mistaken? If your point is that Object.is does not pull its weight, make a stronger case for why people should have to write it by hand. You missed that Object.is(-0, +0) (and with arguments transposed) is false, while -0 === +0. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: RegExp.escape()
Ok, with a ton of help from Domenic I've put up http://benjamingr.github.io/RexExp.escape/ Less cool coloring but more links and motivating examples and so on at https://github.com/benjamingr/RexExp.escape As this is my first attempt at this sort of thing - any non-bikeshed feedback would be appreciated :) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Language design
https://i.imgflip.com/mtot6.jpg On Fri, Jun 12, 2015 at 6:55 PM KOLANICH kola...@mail.ru wrote: Hello all. I have opened the page https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/ECMAScript_6_support_in_Mozilla and was horrified. What happened with JS? Why do we need all this methods? Why a lot of functionality is now doubled, and a lot of new badly designed API and language features was introduced? I understand the word compatibility, but I think that no compatibility worth enough to be preserved sacrificing the language design making it self-contradictary. For example, Object.is compares identity. Operator === also compares identity but in a bit differrent way. Why not just make == check equality only between compatible types, === check identity (that the object is the same) and throw out Object.is. Operator [] casts its argument to string ... but not when used with Symbol (why not just allow the key to be any object and match using ===). New iterator API relyes on Symbol.iterator. Why do we need it? Why not just use strings and prototypes? fromCodePoint doubles fromCharCode, but differs a bit. Why didn't you repurpose fromCharCode, just allowing it to take a string arguments describing codepages? Iterability and enumerability are distinct, but iterability is just enumerability with numeric key (yeah, I know that it is possible to create endless or random iterator, but in fact this means that you just don't need to use the key provided). Why there is iterability, but not enumerability with properties of iterability and enumerability united? Why we need enumerability to make it work with for ... in and iterability to make it work with for ... of? Why can't we use methods definitions to define methods as a function declaration? Why JS is so badly designed? ___ 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: Language design
I'm going to address your questions. `Object.is` - have you checked and read the actual thread in the list explaining the motivation behind that? Operator [] casts its argument to string ... but not when used with Symbol - that's the poit of symbols - to have non string keys that are unique. Reading the motivating symbol thread or a tutorial should clarify the point of symbols and how they solve a hard problem in a rather elegant way. Also it's not an operator. New iterator API relyes on Symbol.iterator. Why do we need it? - to have a uniform way to iterate things that support iterations, much like implementing an interface in a statically typed language or __iter__ in Python. Again, this has been explained a few times in past threads. Why not just use strings and prototypes? - because that would break backwards compatibility and be a less elegant solution, using a symbol also ensures you do not accidentally implement a protocol. fromCodePoint doubles fromCharCode, but differs a bit. it differs a lot. Not that it would matter much since you can't break the whole internet just because you'd like to repurpose something. Code that relies on this is literally used by billions of people and billions of websites. Iterability and enumerability are distinct, but iterability is just enumerability with numeric key (yeah, I know that it is possible to create endless or random iterator, but in fact this means that you just don't need to use the key provided). - in the scope of the spec enumerability is of object keys and iterability is iteration of an iterator. Not everything has its keys iterated - the reason an iteration protocol is needed is to make this distinction - how would you iterate a `Map` or a `Set` or any other non array-or-object collection? This is why every other language defines this form of protocol (From c++ to Java and C# and Scala to dynamic languages like Python to purely functional ones like Erlang and Haskell) and why ES does too. Why can't we use methods definitions to define methods as a function declaration? I have no idea what you were trying to say here, sorry. Why JS is so badly designed? for the same reason other languages are. JS has quite the back story, a lot of baggage and hindsight is always 20/20. Every language sells you the awesome story until you use it - I'd argue other languagesl like Python and Haskell have as much if not more baggage. Ignoring the fact asking this is completely pointless and needlessly argumentative - language design is really hard. If you're interested in what motivated a lot of the things in ES - please the material is out there go read it :) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: RegExp.escape
Reviving this, a year passed and I think we still want this. We have even more validation than we had a year ago (added by libraries like lodash) and this is still useful. What would be the required steps in order to push this forward to the ES2016 spec? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: RegExp.escape
At risk of bikeshed, I think I would prefer syntax for it, personally, e.g.:
let myRegExp = /\d+\./{arbitrary.js(expression)}/SOMETHING$/;
(ASI issues notwithstanding) vaguely matching the idea of template strings.
I prefer this kind of thing to be structured at the parse-level rather than
relying on runtime string stitching and hoping for a valid parse.
Cheers
On Friday, June 12, 2015, Benjamin Gruenaum benjami...@gmail.com wrote:
Reviving this, a year passed and I think we still want this.
We have even more validation than we had a year ago (added by libraries
like lodash) and this is still useful.
What would be the required steps in order to push this forward to the
ES2016 spec?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: RegExp.escape
The primary advantage to making it be a function (also doing it as syntax
would be great too!) is that it's polyfillable, which means that all
browsers could instantly take advantage of known-safe regex escaping.
On Fri, Jun 12, 2015 at 11:34 AM, Alexander Jones a...@weej.com wrote:
At risk of bikeshed, I think I would prefer syntax for it, personally,
e.g.:
let myRegExp = /\d+\./{arbitrary.js(expression)}/SOMETHING$/;
(ASI issues notwithstanding) vaguely matching the idea of template
strings. I prefer this kind of thing to be structured at the parse-level
rather than relying on runtime string stitching and hoping for a valid
parse.
Cheers
On Friday, June 12, 2015, Benjamin Gruenaum benjami...@gmail.com wrote:
Reviving this, a year passed and I think we still want this.
We have even more validation than we had a year ago (added by libraries
like lodash) and this is still useful.
What would be the required steps in order to push this forward to the
ES2016 spec?
___
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: RegExp.escape
I believe you need to champion the issue. Create a Github repository and start editing the fragment of the spec. I do not believe that the issue is contentious. The color of the shed is obvious. The only thing missing is a champion willing to do the writing. On Fri, Jun 12, 2015 at 10:52 AM, Benjamin Gruenaum benjami...@gmail.com wrote: Reviving this, a year passed and I think we still want this. We have even more validation than we had a year ago (added by libraries like lodash) and this is still useful. What would be the required steps in order to push this forward to the ES2016 spec? ___ 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
