To confirm what Allen already mentioned: I too concluded from the
discussion that we would remove [[Invoke]] from ES6.
It is one of a few items I would like to put on the agenda of the TC39
November meeting to get a definitive consensus (the other item being the
removal of the hasOwn() trap, for
2013/10/18 Till Schneidereit t...@tillschneidereit.net
I share this concern. Last time we discussed it, Brendan said that we
could implement it by falling back to .get if .invoke isn't
defined[1]. I'm not sure how well that fits into the rest of the Proxy
design, though.
It doesn't fit the
Hey everyone.
I've talked to about 100 developers whose primary language is JS this last
week (although I admit it was not a balanced survey, mainly people I know).
Most of them (Over 80) do not feel that the problem I've mentioned before
in scoped method extensions is a real problem they have to
There is another thread covering this exact topic at the moment. See
Scooped binding of a method to an object.
On Oct 21, 2013 12:49 AM, Jonathan Barronville jonat...@belairlabs.com
wrote:
Hi everyone.
I have a proposal for ES6. I don't know if it's been discussed before, so
if it has, I
2013/10/18 Rick Waldron waldron.r...@gmail.com
@Tom - since you know the status of the more recent Proxy wiki pages
better than I do, would you mind adding the same h1 text to those that fit
the description of obsolete? Thanks!
Done!
___
es-discuss
2013/10/18 Allen Wirfs-Brock al...@wirfs-brock.com
This is what I currently have in my working draft of the ES6 spec:
[...]
In other words:
you can say:
Proxy(traget,handler)
but not
new Proxy(target, handler)
It would be easy enough to allow
new
On Mon, Oct 21, 2013 at 9:16 AM, Erik Arvidsson erik.arvids...@gmail.comwrote:
There is another thread covering this exact topic at the moment. See
Scooped binding of a method to an object.
Can you clarify the overlap? Thanks!
Rick
On Oct 21, 2013 12:49 AM, Jonathan Barronville
When we proposed scoped object extensions we looked at Ruby's refinements.
On Mon, Oct 21, 2013 at 11:25 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Oct 21, 2013 at 8:19 AM, Rick Waldron waldron.r...@gmail.com wrote:
On Mon, Oct 21, 2013 at 9:16 AM, Erik Arvidsson
On Oct 21, 2013, at 7:20 AM, Tom Van Cutsem wrote:
I agree with your line of reasoning and I would be happy if proxies can be
created without `new`. However, I don't see how the above spec disallows the
use of `new`. With the above definition, won't `new Proxy(target, handler)`
just
On Mon, Oct 21, 2013 at 8:19 AM, Rick Waldron waldron.r...@gmail.com wrote:
On Mon, Oct 21, 2013 at 9:16 AM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
There is another thread covering this exact topic at the moment. See
Scoped binding of a method to an object.
Can you clarify the
Which were inspired by the classbox work that built on Smalltalk classes.
/be
On Oct 21, 2013, at 8:29 AM, Erik Arvidsson erik.arvids...@gmail.com wrote:
When we proposed scoped object extensions we looked at Ruby's refinements.
On Mon, Oct 21, 2013 at 11:25 AM, Tab Atkins Jr.
This thread is based on conversations in the Scoped binding of a method to
an object discussion. I suggested using the proposed bind operator :: as
an alternative, and hinted at way of doing so polymorphically. Given that
the other discussion on refinements just popped up, I figured I might as
2013/10/21 Allen Wirfs-Brock al...@wirfs-brock.com
see
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-standard-built-in-ecmascript-objects
Paragraph 9:
Built-in functions that are not identified as constructors do not
implement the [[Construct]] internal method unless otherwise
A well-known problem with Promises, as implemented in various Javascript
libraries, is that program errors are silenced by default. Consider the
following program, which simply makes an HTTP request and then prints out
the HTTP response headers:
Russell Leggett russell.legg...@gmail.com wrote:
https://gist.github.com/genericallyloud/7086380
Very interesting.
// 4. use the default if available
what's the default in #4? The protocol's default? What's the behavior if
no matching method is found?
Also, can anyone explain why this
Requiring early registration prevents the use of futures as value
containers; i.e. kicking off an operation and storing the Future somewhere
so anyone can use it at a later date.
I agree that an improved error handling policy would be very, very good to
have, though.
On Mon, Oct 21, 2013 at
On Mon, Oct 21, 2013 at 3:17 PM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
Russell Leggett russell.legg...@gmail.com wrote:
https://gist.github.com/genericallyloud/7086380
Very interesting.
// 4. use the default if available
what's the default in #4? The protocol's default?
A well-known problem with loops, as implemented in various programming
languages, is that infinite loops are silenced by default. Consider the
following program, which simply adds some numbers in a loop:
```js
var sum = 0;
while (Math.random() config.loopLimt) { // Note the misspelling!
sum
wouldn't events better suit and better solve the problem ?
fetchUri(http://someauthority.com/;).on('load', response = {
repsonse.heders() });
at least this is how it works in eddy.js and I've never had silent errors
in current specs would be an addEventListener() within the XHR object
On
On Mon, Oct 21, 2013 at 11:25 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Mon, Oct 21, 2013 at 8:19 AM, Rick Waldron waldron.r...@gmail.com
wrote:
On Mon, Oct 21, 2013 at 9:16 AM, Erik Arvidsson
erik.arvids...@gmail.com
wrote:
There is another thread covering this exact topic at
Requiring early registration prevents the use of futures as value
containers; i.e. kicking off an operation and storing the Future somewhere
so anyone can use it at a later date.
One can always do that, provided that you register an error handler *before
your call stack is cleared*.
{ Kevin
Great, thanks for the clarifications. A few more scenarios:
- Case 1:
I have an object O of type Foo. A protocol P.
- O has the structure {x:5,foo:7};
- The protocol implements `foo` but does not specifically for Foo (via
.defaults).
What happens? Does `P.foo` get invoked, or do we get
Domenic,
First, your caricature of my position is patently ridiculous.
Second, can you or someone else offer a clear use case which requires
undecidable error handling semantics? I have asked for examples several
times and so far I haven't seen anything convincing. Usually that
indicates that
I don't think that's the same thing at all.
Detecting an infinite loop is _extremely_ hard at most cases (and of course
impossible at others. However instead of discussing the halting problem, I
think what's bothering this guy is that `.then` does not throw an error
when an error occurs within it
You have been given examples in several previous conversations, but have chosen
to not find them convincing. I (and others) tire of rehashing this argument
with you monthly.
I instead responded to the novel content of your post, which was some sort of
attempt to claim that a language feature
Kevin I have no idea which library you are using but if you do this:
```
fetchUri(http://someauthority.com/;).then(response = {
for (let header of repsonse.heders) // Note the misspelling!
console.log(header.key, header.value);
}).then(Object, function error(e) {
I'll preface this by saying that I haven't made a formal proposal and this
isn't an actual library. You're doing a good job of spotting some undefined
behavior which would probably be better defined by trying it out. I'll give
my opinions on them, but it could all use a good test drive before
On Tue, Oct 22, 2013 at 12:15 AM, Russell Leggett russell.legg...@gmail.com
wrote:
I'll preface this by saying that I haven't made a formal proposal and
this isn't an actual library. You're doing a good job of spotting some
undefined behavior which would probably be better defined by trying it
+1
Nathan
Domenic Denicola wrote:
A well-known problem with loops, as implemented in various programming
languages, is that infinite loops are silenced by default. Consider the
following program, which simply adds some numbers in a loop:
```js
var sum = 0;
while (Math.random()
It has been shown that delayed registration, in general, is useful.
However, it has not been demonstrated that delayed registration of a
primary error handler is necessary.
If use cases have been provided, then please provide links. Otherwise,
let's not use ad hominem in place of logic.
{
Allen Wirfs-Brock wrote:
Actually, this is a good point. As currently specified Object.assign
of with an own __proto__ property on the RHS object will trigger a
[[SetPrototypeOf]] on the LHS object. Is that what we want. It is a
direct fallout of specifying Object.assign as the equivalent of
On Mon, Oct 21, 2013 at 10:28 PM, Nathan Wall nathan.w...@live.com wrote:
Allen Wirfs-Brock wrote:
Actually, this is a good point. As currently specified Object.assign
of with an own __proto__ property on the RHS object will trigger a
[[SetPrototypeOf]] on the LHS object. Is that what we
In reading Rick's response, I noticed my comments were rather messy
themselves. Correcting for clarity.
Given that `__proto__` is defined as an accessor on `Object.prototype`,
I think this should be expected. Any other setter defined on the object
or its prototype chain will be invoked in
As sanity/integrity check, `Object.assign` should be something like this to
me ...
```javascript
for (var property in source) {
if (Object.prototype.hasOwnProperty.call(source, key)) {
if (key in target) {
Object.defineProperty(
target, key,
On Mon, Oct 21, 2013 at 11:18 PM, Nathan Wall nathan.w...@live.com wrote:
In reading Rick's response, I noticed my comments were rather messy
themselves. Correcting for clarity.
Given that `__proto__` is defined as an accessor on `Object.prototype`,
I think this should be expected. Any
On Mon, Oct 21, 2013 at 11:26 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
As sanity/integrity check, `Object.assign` should be something like this
to me ...
```javascript
for (var property in source) {
if (Object.prototype.hasOwnProperty.call(source, key)) {
if (key in
just one thought on this ...
On Mon, Oct 21, 2013 at 8:34 PM, Rick Waldron waldron.r...@gmail.comwrote:
It may be beneficial, in the long run, to make it painful to use
__proto__.
proto made IE life painful until now and TC39 decided to leave it in specs
... IE11 had to adopt it to not be
Rick Waldron wrote:
If this were how it was defined, I would say get rid of it and
practitioners will carry on using their own non-nanny implementations.
If it can't invoke setters then it loses properties like innerHTML.
eg.
Object.assign(div, {
innerHTML: `${name}BR`,
id: an-id,
Sure thing Rick, I will definitely do that.
I'd love to hear any current thoughts and feedback around the idea though.
Thanks!
- Jonathan Barronville
@jonathanmarvens
On October 21, 2013 at 1:26:57 AM, Rick Waldron (waldron.r...@gmail.com) wrote:
On Sun, Oct 20, 2013 at 9:01 AM, Jonathan
39 matches
Mail list logo
