My understanding was that it'd look like this:
// presumably standard
class CancelReason extends Error {}
// Promise.cancelable? third party library?
function cancelable(p, onCancel){
// todo: refactor into utility function allowing: return
cancelable(resultPromise, () = {xhr.abort()})
var
AsyncJS (http://github.com/rbuckton/asyncjs) uses a separate abstraction for
cancellation based on the .NET CancellationTokenSource/CancellationToken types.
You can find more information about this abstraction in the MSDN documentation
here:
On Fri, Feb 27, 2015 at 7:49 PM, John Lenz concavel...@gmail.com wrote:
Closure Library's promise implementation supports cancel:
https://github.com/google/closure-library/blob/master/closure/goog/promise/promise.js#L502
A promise is cancelled only if all the child promises are also
What is cancelable is the value of the fetch() promise, not the fetch
itself. Extending the promise API is extending the concept of control flow
and I think this require a separated discussion. To make fetch() to be
cancelable should not affect promises at all.
TL;DR; I think the cancelable
AsyncJS (http://github.com/rbuckton/asyncjs) uses a separate abstraction
for cancellation based on the .NET
CancellationTokenSource/CancellationToken types. You can find more
information about this abstraction in the MSDN documentation here:
noone? JSLint doesn't even let you write a for/in loop if you don't have
`obj.hasOwnProperty(key)` in it, and usually nobody wants inherited
properties (included methods from old classes/ahem prototypes) reassigned
everywhere.
If you deal with data objects and dictionaries yuo'll always have a
On Feb 27, 2015, at 12:27 AM, Leon Arnott wrote:
I feel a little unhappy that one meta-property, `new.target`, is lexically
scoped in arrow functions but these new ones aren't, without much obviously
distinguishing them. I guess you could concoct the reasoning that since
arrows can't be
Why do arrow functions need to reflect on themselves? I think it is more
useful for all code directly inside a non-arrow function to be able to
reflect on that non-arrow function. If I wrote an arrow function and then
found I wanted it to reflect on itself, I'd be happier rewriting it as a
On Feb 27, 2015, at 7:59 AM, Claus Reinke wrote:
For concise methods, the problem is already solved by 'this',
isn't it?
({f(n){return n1?n*this.f(n-1):1}}.f)(6)
720
No, not for the general case. You could have arrived here via a 'super' method
call in which case 'this.f' will take
That is not what people relying in Object.assign and ES6 will write,
because you cannot define properties in a generic class, only methods.
Moreover, back to your ES5/3compat example, if you have a person object,
you **never** inherit name, you always have your own name as you explicitly
set
answering inline ...
On Fri, Feb 27, 2015 at 2:22 PM, Andri Möll an...@dot.ee wrote:
noone? JSLint doesn't even let you write a for/in loop if you don't have
`obj.hasOwnProperty(key)` in it, and usually nobody wants inherited
properties (included methods from old classes/ahem prototypes)
On Feb 27, 2015, at 8:00 AM, Rick Waldron wrote:
I was thinking exactly this while I was reading Allen's post.
Would class method definitions use `class.*`? Seems like the wrong
abstraction..? Maybe all functions and method definitions use `function`,
while arrows use `=` (or whatever)
ES3 these are all enumerable, you don't want methods copied all over your
objects each time because that's the entire point of having prototypal
inheritance, right? If instead of inheriting and composing you copy
everything as enumerable, writable, and configurable, that's your choice, not
Mark many framewors/libraries/younameit attach listeners at construction
time, there is where everyone feels like it's cool and fast and better, and
shorter to use arrow functions, then they have to mix between removable
listeners and not.
I personally pass objects as listeners, providing an
noone? JSLint doesn't even let you write a for/in loop if you don't have
`obj.hasOwnProperty(key)` in it, and usually nobody wants inherited
properties (included methods from old classes/ahem prototypes) reassigned
everywhere.
Huh? Old prototypes? Those prototypes have their properties set
On 27 February 2015 at 15:22, Andri Möll an...@dot.ee wrote:
noone? JSLint doesn't even let you write a for/in loop if you don't have
`obj.hasOwnProperty(key)` in it, and usually nobody wants inherited
properties (included methods from old classes/ahem prototypes) reassigned
everywhere.
You are talking about flatting all properties, which is an undesired
overhead.
```js
var b = Object.create(
Object.getPrototypeOf(a)
);
Object.assign(b, a);
```
But what's bugging me every time more, is that somebody had a very bad idea
to spread `Object.assign` as something good for
You are talking about flatting all properties, which is an undesired
overhead.
Umm, Object.assign is as it is because of performance? I don’t think it is nor
is that a good reason. Every property access in JavaScript takes inheritance
into account and there are thousands more than a
On Fri, Feb 27, 2015 at 10:56 PM, Andri Möll an...@dot.ee wrote:
Prototypes aren't only useful for sharing behavior. They’re just as
useful for data objects and value types.
They, er, sort of aren't. One big deal is that you can't `JSON.stringify()`
them, because that ignores inherited
nope, you are limiting your object to have only one listener per event, I
think that's not quite how reality is. You gonna lose that listeners next
time somebody use same name with the same object.
In (?:io|node)js you have EventEmitter that exposes .on, on web even jQuery
needs that reference in
For concise methods, the problem is already solved by 'this',
isn't it?
({f(n){return n1?n*this.f(n-1):1}}.f)(6)
720
No, not for the general case. You could have arrived here via a 'super' method call in which case
'this.f' will take you back to a subclass' f rather then recurring on
and yet you haven't removed any anonymous arrow listener. Assign first?
Mostly nobody will do that, it's just less natural then `obj.on(something,
()=happening)`
personally? Yes, I tend to assign listeners somewhere, at least when I
intend to remove them later. I've even been known to assign
They, er, sort of aren't. One big deal is that you can't `JSON.stringify()`
them, because that ignores inherited properties.
Indeed, I too think JSON.stringify is poorly designed in that respect,
especially because, adding insult to injury, inheritance _is_ considered when
searching for
On Thu Feb 26 2015 at 8:22:55 PM Claude Pache claude.pa...@gmail.com
wrote:
Le 27 févr. 2015 à 02:04, Allen Wirfs-Brock al...@wirfs-brock.com a
écrit :
On Feb 26, 2015, at 3:55 PM, Mark S. Miller wrote:
For most of these, my first reaction is meh. They all make sense and
violate no
Can you show an example of how callee is used with a fat arrow function?
((n)=n1? n*function.callee(n-1) : 1)
meta-level tools are powerful, which makes them ever so tempting.
They are too powerful to be used for tasks for which current
language-level tools are sufficient. Using a
On 27 February 2015 at 16:16, Andri Möll an...@dot.ee wrote:
The fragile base class problem is one.
That’s a problem of the caller, not the callee, the user of Object.assign.
If I decide to use inheritance, that’s my risk.
You would like it to be that way, but that's not how it plays out
nope, you are limiting your object to have only one listener per event, I
think that's not quite how reality is. You gonna lose that listeners next
time somebody use same name with the same object.
true. For cases where that isn't enough, i assume you're thinking of
canceling from within the
I think the fact you had to write two solutions where one attach to the
object the listener and another one needs a double arrow (rainbow) already
shows we have a hole in the language once covered by arguments.callee.
The more you write examples, the more you convince me we are missing callee
;-)
That is not what people relying in Object.assign and ES6 will write, because
you cannot define properties in a generic class, only methods.
Classes are just syntactic sugar over prototypes after all. I’m definitely
going to continue promoting use of plain old prototypical approaches in
FWIW I do like prototypal inheritance ... but ...
On Fri, Feb 27, 2015 at 8:45 PM, Andri Möll an...@dot.ee wrote:
That is not what people relying in Object.assign and ES6 will write,
because you cannot define properties in a generic class, only methods.
Classes are just syntactic sugar over
I feel a little unhappy that one meta-property, `new.target`, is lexically
scoped in arrow functions but these new ones aren't, without much obviously
distinguishing them. I guess you could concoct the reasoning that since
arrows can't be `new`'d, `new.[meta-property]` is meaningless in it - but
On Fri Feb 27 2015 at 5:31:51 PM Andri Möll an...@dot.ee wrote:
`Object.assign` has **nothing to do with inheritance**, that's what I am
saying, not just supporting.
What is my personal position here is that `Object.assign` is the wrong
method/tool/function to do anything prototypal or
So there is code misusing Object.assign? This operation is _not_ for
inheritance, it's for batch property assignment of own properties.
Sorry, I assumed my point was clear from previous emails and used fucking up
inheritance” as a reference. I meant not that it doesn’t create a new object
Rick Waldron wrote:
function Component(target) {
let a = function.arguments;
target.on(click, event = {
// In here, `arguments` refers to the `arguments` object
// that was created for this invocation of Component,
// which makes sense because that object has no sense of
//
Oh, I’ve forgotten we’ve had this argument with _you_ over at the Node.js bug a
while back. Long time no see.
1) Did you even read the issue I linked to? It ended with _agreement_ that
IO.js _should_ support inherited properties.
2) @jdalton did _not_ “exhaustively” answer with arguments
lodash has more downloads than underscore and it does not suffer these kind
of little gotchas:
https://twitter.com/jdalton/status/568575738086993920
It's a huge community and JD agrees with Leon Arnott points, after all
points he, me, and others, alrThiseady made about this matter.
This
On Thu, Feb 26, 2015 at 11:43 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
AFAIK bluebird did:
https://github.com/petkaantonov/bluebird/blob/master/API.md#cancelerror-reason---promise
But I agree once you've made Promises more complex than events ( xhr in this
case ) nobody wins
Re fetch: https://github.com/whatwg/fetch/issues/20
On Fri, 27 Feb 2015 23:08 Jonas Sicking jo...@sicking.cc wrote:
On Thu, Feb 26, 2015 at 11:43 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
AFAIK bluebird did:
`Object.assign` has **nothing to do with inheritance**, that's what I am
saying, not just supporting.
What is my personal position here is that `Object.assign` is the wrong
method/tool/function to do anything prototypal or classical inheritance
related.
Are we entirely missing each
I think your issue is not real, since the bug you linked is indeed closed
and the one you opened has been exhaustively answered bu John who's the
main person behind lo-dash, the drop-in replacement for underscore.
https://github.com/joyent/node/issues/7587#issuecomment-42560846
and the let it go
Hello,
Why does Object.assign ignore inherited enumerable properties?
What is the problem to which ignoring inherited properties is the solution to?
All I can see is that it prevents a useful use of inheritance. The Liskov
substitution principle was mentioned 27 years ago in ’87. Why is
41 matches
Mail list logo
