Hi,
I was wondering whether it was any useful to have the thisArg argument
in Array#find and Array#findIndex.
As of ES6, the language has Function.prototype.bind and arrow functions
and I would imagine these to be enough to cover any use case where
thisArg would be used.
I know that in the
Le 10 juil. 2013 à 11:26, David Bruant bruan...@gmail.com a écrit :
Hi,
I was wondering whether it was any useful to have the thisArg argument in
Array#find and Array#findIndex.
As of ES6, the language has Function.prototype.bind and arrow functions and I
would imagine these to be
Just a humble attempt to propose some addiction to the `Object.prototype` I
already know many will kill me for even trying to ...
**tl;dr** - everything proposed can be already tested through this utility
called [eddy.js](https://github.com/WebReflection/eddy#event-driven-js)
### Event Target
Hi all,
What is the current expected way for an author to throw a custom
errors? You obviously could do something like:
throw { reason: TimeoutError };
or
throw TimeoutError;
However that makes it very hard for anyone receiving an exception to
inspect what it is. I.e. you'd first have to check
In some browsers, using the native Error class enables cool features like
automatic stack trace.
Just in case you need special kind of Error (ie: subclasses), I recommend doing
it that way:
function SomeError(message) {
// the real instance should be an Error:
var self = new
Woah, François, that seems pretty overcomplicated; why not replace everything
inside the constructor with `this.message = message`? It has the same effect in
the browsers I've seen. (Also don't forget `SomeError.prototype.constructor =
SomeError`.)
Anyway, to Jonas's point: I think `DOMError`
Le 10/07/2013 14:48, Claude Pache a écrit :
Le 10 juil. 2013 à 11:26, David Bruant bruan...@gmail.com a écrit :
Hi,
I was wondering whether it was any useful to have the thisArg argument in
Array#find and Array#findIndex.
As of ES6, the language has Function.prototype.bind and arrow
David Bruant wrote:
I can't find it anymore, but I read a message from Mike Shaver (I
think it was him) saying that these methods have been standardized
after SpiderMonkey implementation without other form of rationale.
Who needs this particular consistency anyway?
Users generally benefit
Le 10/07/2013 16:53, Andrea Giammarchi a écrit :
Just a humble attempt to propose some addiction to the
`Object.prototype` I already know many will kill me for even trying to
...
**tl;dr** - everything proposed can be already tested through this
utility called
Hi Jonas,
As an example from the field, here is how we extend our own error types:
https://github.com/imvu/imvujs/blob/master/src/error.js
You can either switch on e.name or use e instanceof ErrorType in your catch
handler.
Like Francois's approach, it also preserves the 'stack' property if the
In addition to the perf savings from not having to allocate (to call bind)
not needing to use bind() for cases like .find() can have beneficial
effects for JITs as well. It's my understanding that at a recent point in
time (maybe even still today?) functions created by bind() had the ability
to
Events are already part of the interface of objects as people use them:
* in Node.js, events are documented at the same level than properties and
methods.
* In new FirefoxOS WebAPIs, pretty much every new object inherits from
EventTarget.
I don't think that Node.js is a relevant example here.
I'd rather do something like:
Object.addEventListener(obj, eventName, function(){});
I think this matches very closely the way you do property descriptors and
I'd love to see
var obj = {
on eventName() {}
}
On Wed, Jul 10, 2013 at 10:33 AM, David Bruant bruan...@gmail.com wrote:
Le
Le 10/07/2013 19:28, Brendan Eich a écrit :
David Bruant wrote:
I can't find it anymore, but I read a message from Mike Shaver (I
think it was him) saying that these methods have been standardized
after SpiderMonkey implementation without other form of rationale.
Who needs this particular
Le 10/07/2013 19:57, Jeremy Martin a écrit :
Events are already part of the interface of objects as people use them:
* in Node.js, events are documented at the same level than properties
and methods.
* In new FirefoxOS WebAPIs, pretty much every new object inherits
from EventTarget.
I
Le 10/07/2013 20:00, Matthew Robb a écrit :
I'd rather do something like:
Object.addEventListener(obj, eventName, function(){});
I think this matches very closely the way you do property descriptors
and I'd love to see
var obj = {
on eventName() {}
}
That's the spirit. I don't care for
On Wed, Jul 10, 2013 at 2:19 PM, David Bruant bruan...@gmail.com wrote:
This madness really has to stop. We need first class events (and I'm praying
for a way to retrofit them into the DOM if possible)
If you don't do the latter, I wonder how you'll achieve the former.
--
On further thought I think doing something like:
Object.defineEventListener(obj, eventName, {
handler: function(){},
phase: before // , after, defaults to `on`
});
AND
var obj = {
on eventName(){},
after eventName(){},
before eventName(){}
}
On Wed, Jul 10, 2013 at 11:22 AM, David Bruant
Le 10/07/2013 20:27, Anne van Kesteren a écrit :
On Wed, Jul 10, 2013 at 2:19 PM, David Bruant bruan...@gmail.com wrote:
This madness really has to stop. We need first class events (and I'm praying
for a way to retrofit them into the DOM if possible)
If you don't do the latter, I wonder how
Yeah, so what I meant was how you'd stop the madness if you don't do
them in a way that works with DOM (as DOM works today). My bad.
--
http://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
(like, say, the way Jeremy Martin proposed)
FTR, I haven't proposed anything just yet :)
Although if I did, I think I would be more fond of something like:
Object.mixin({ foo: 'bar' }, EventEmitter);
... that is, I can see the value of events as an object-level API that
doesn't imply actual
On Wed, Jul 10, 2013 at 12:52 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Woah, François, that seems pretty overcomplicated; why not replace everything
inside the constructor with `this.message = message`? It has the same effect
in the browsers I've seen. (Also don't forget
my implementation works already with `DOM` nodes and browser environment,
including `window`.
I've also already written an `EventTarget` mixin object but in my case I'd
use that via `Object.mixin(Object.prototype, EventTarget);` 'cause almost
every object I use in my logic should be observed or
You can do chainability at object define time with the sugar form:
var obj = {
on type1(){},
on type2(){},
on type3(){}
}
OR add to it using one of the following options:
Object.mixin(obj, {
on type1(){},
on type2(){},
on type3(){}
})
obj.{
on type1(){},
on type2(){},
on type3(){}
}
obj := {
David Bruant wrote:
Le 10/07/2013 19:28, Brendan Eich a écrit :
David Bruant wrote:
I can't find it anymore, but I read a message from Mike Shaver (I
think it was him) saying that these methods have been standardized
after SpiderMonkey implementation without other form of rationale.
Who
Jonas, DOM never throws DOMError. DOMErrors are used for other error
mechanisms, such as callbacks. [1]
The DOM spec does however throw DOMException objects [2]. These are
instanceof Error (see WebIDL [3])
var ex;
try {
document.appendChild(document);
} catch (e) {
ex = e;
}
assert(ex
On Wed, Jul 10, 2013 at 3:49 PM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
In Blink DOMException also have a stack property
assert(stack in ex);
Since they are just Error objects
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
From: Jonas Sicking [jo...@sicking.cc]
Note that
```js
(new DOMError) instanceof Error;
```
returns false. So the DOM does do the strongly discouraged thing. Is this
ok or bad?
This is horrible! I had no idea! It should definitely derive from `Error`.
Also, the DOM does not create a
I know but people use prefixes and unique ids for events too and I am not
sure if that would work so well.
Also, this is not backward compatible, or better, this is impossible to
polyfill so it won't bring benefits to the current scenario.
If only I could already `Object.mixin(Object.mixin({},
It's not too late for find and findIndex, and they do fit the pattern.
Is an options object as the last parameter out of the question? For find(), I’d
love to have the option to specify a result other than `undefined` if the value
isn’t found. Such a result would be an option, as would be
Also, who needs to find undefined? It's a good notFound default value
but I go further: it is the only notFound you're gonna need. IOW, YAGNI.
/be
Brendan Eich wrote:
Axel Rauschmayer wrote:
It's not too late for find and findIndex, and they do fit the pattern.
Is an options object as the
I am not sure where this conversation ended up so I hope I am not repeating
already said stuff but you can always create constructors that inherits
from Error and set the name.
```javascript
function CustomError(message) {
this.message = message || '';
}
CustomError.prototype = new Error;
```javascript
function CustomError(message) {
this.message = message || '';
}
CustomError.prototype = new Error;
// whenever you need
throw new CustomError;
```
At best, this will not preserve the stack trace property, at worse this will
lead to a bad one.
```javascript
function CustomError(message) {
this.message = message || '';
}
CustomError.prototype = new Error;
// whenever you need
throw new CustomError;
```
At best, this will not preserve the stack trace property, at worse this will
lead to a bad one.
Because the location info will
Le 10 juil. 2013 à 19:05, David Bruant bruan...@gmail.com a écrit :
Who needs this particular consistency anyway?
IMO, when designing an API, the right question is not: Why would I be
consistent in that particular case?, but: Why would I be inconsistent in that
particular case? You didn't
On Wed, Jul 10, 2013 at 3:13 PM, Claude Pache claude.pa...@gmail.com wrote:
Le 10 juil. 2013 à 19:05, David Bruant bruan...@gmail.com a écrit :
Who needs this particular consistency anyway?
IMO, when designing an API, the right question is not: Why would I be
consistent in that particular
Because the location info will be that of the new Error? One could
try this instead, which seems to work for me:
throw { __proto__ : new Error(), reason: Monday }
That one seems to be working (except in IE11 since IE didn't support __proto__
prior to that). That somehow surprises me that
I don't want any of this on my Object objects. Not all objects represent
something that can or should emit/publish/trigger/broadcast.
For example...
class Light {
constructor() {
// initialize Light control instance
}
on() {
// send bits to turn Light on
}
off() {
// send
I think at this point we have a long history of language designs where
random stuff has been tacked onto the core base class (i.e. Object) that
really shouldn't have gone there - hashCode/toString in Java/C#, etc - such
that any proposal to put something on Object instances deserves extreme
yep, I thought it was about having meaningful red errors with a proper name
in console. The stack can be addressed passing the `new CustomError
(new Error('message'))`
using error as argument, not big deal ... abusing __proto__ for this seems
like the wrong answer to a concrete problem
On Wed,
On Jul 9, 2013, at 6:09 PM, Mark S. Miller wrote:
FWIW, we include 2**53 as in the contiguous range of exactly representable
natural numbers.
https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#492
What you want is: the continuous range of
Consider this simple construct:
module test {
export function setVar() {
gvar = GVAR; // note 'gvar' is not defined in the module
}
export function getVar() {
return gvar;
}
}
module Test from test;
Having this in place I am calling
Test.setVar();
inline ...
On Wed, Jul 10, 2013 at 3:57 PM, Rick Waldron waldron.r...@gmail.comwrote:
I don't want any of this on my Object objects. Not all objects represent
something that can or should emit/publish/trigger/broadcast.
For example...
class Light {
constructor() {
// initialize
What's wrong with:
```javascript
throw new CustomError('message')
function CustomError(message /* accept any custom arguments here */) {
Error.call(this, message)
this.name = 'CustomError'
/**
* add any custom error info here
*/
}
CustomError.prototype = Object.create(Error)
On Wed, Jul 10, 2013 at 7:15 PM, Andrew Fedoniouk n...@terrainformatica.com
wrote:
Consider this simple construct:
module test {
export function setVar() {
gvar = GVAR; // note 'gvar' is not defined in the
module
}
export function getVar() {
false.hasOwnProperty('whatever');
1.0.isPrototypeOf({whate:'ver'});
'string'.propertyIsEnumerable('whatever')
these are already examples of an over-polluted prototype with methods
nobody uses ... I thought 4 extra methods everyone is using same way except
for Rick that honorees Tesla in this day
wrong at least two things for the non ES6 version
1. `Error.call(this, message)` does not do what you think it should do
2. `CustomError.prototype = Object.create(Error)` has a typo, you meant `
Object.create(Error.prototype)`
In the ES6 version, I am not sure about constructors and classes,
On Wed, Jul 10, 2013 at 7:24 PM, Rick Waldron waldron.r...@gmail.com wrote:
It gets created nowhere,
This is right.
because the body of a module is implicitly strict,
And this is right.
so the above code produces a Reference Error.
But this is incorrect, because modules check that their
On Wed, Jul 10, 2013 at 4:24 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Wed, Jul 10, 2013 at 7:15 PM, Andrew Fedoniouk
n...@terrainformatica.com wrote:
Consider this simple construct:
module test {
export function setVar() {
gvar = GVAR; // note 'gvar'
On Wed, Jul 10, 2013 at 4:40 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Wed, Jul 10, 2013 at 7:24 PM, Rick Waldron waldron.r...@gmail.com wrote:
It gets created nowhere,
This is right.
because the body of a module is implicitly strict,
And this is right.
so the above code
On Jul 10, 2013, at 4:32 PM, Andrea Giammarchi wrote:
wrong at least two things for the non ES6 version
1. `Error.call(this, message)` does not do what you think it should do
2. `CustomError.prototype = Object.create(Error)` has a typo, you meant
`Object.create(Error.prototype)`
In
On Jul 10, 2013, at 4:40 PM, Sam Tobin-Hochstadt wrote:
On Wed, Jul 10, 2013 at 7:24 PM, Rick Waldron waldron.r...@gmail.com wrote:
It gets created nowhere,
This is right.
because the body of a module is implicitly strict,
And this is right.
so the above code produces a Reference
Once again, this problem goes beyond simply polluting the prototype (which
is enough of an issue by itself). The semantics for Emitters are somewhat
of an 80/20 thing: 80% of all emitters need some common behavior, but the
remaining 20% is custom.
Going back to Node.js, for instance: everything
On Wed, Jul 10, 2013 at 7:40 PM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote:
On Wed, Jul 10, 2013 at 7:24 PM, Rick Waldron waldron.r...@gmail.com
wrote:
It gets created nowhere,
This is right.
because the body of a module is implicitly strict,
And this is right.
so the above code
On Wed, Jul 10, 2013 at 7:49 PM, Andrew Fedoniouk n...@terrainformatica.com
wrote:
On Wed, Jul 10, 2013 at 4:24 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Jul 10, 2013 at 7:15 PM, Andrew Fedoniouk
n...@terrainformatica.com wrote:
Consider this simple construct:
node.js allows same listener type with same handler multiple times ... but
it has `maxListeners` number which is kinda pointless if events are not
even tracked and can be duplicated.
node also has this thing that you can drop everything from an emitter even
if you don't own registered events
On Wed, Jul 10, 2013 at 8:02 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jul 10, 2013, at 4:40 PM, Sam Tobin-Hochstadt wrote:
On Wed, Jul 10, 2013 at 7:24 PM, Rick Waldron waldron.r...@gmail.com wrote:
It gets created nowhere,
This is right.
because the body of a module is
inline...
On Wed, Jul 10, 2013 at 7:22 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
inline ...
On Wed, Jul 10, 2013 at 3:57 PM, Rick Waldron waldron.r...@gmail.comwrote:
I don't want any of this on my Object objects. Not all objects represent
something that can or should
On Wed, Jul 10, 2013 at 9:14 PM, Mark S. Miller erig...@google.com wrote:
On Wed, Jul 10, 2013 at 6:06 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
No, that's not what I mean. The semantics we've discussed multiple
times are that modules are compiled with respect to the global object
On Wed, Jul 10, 2013 at 7:27 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
false.hasOwnProperty('whatever');
1.0.isPrototypeOf({whate:'ver'});
'string'.propertyIsEnumerable('whatever')
these are already examples of an over-polluted prototype with methods
nobody uses ... I
On Wed, Jul 10, 2013 at 6:16 PM, Rick Waldron waldron.r...@gmail.comwrote:
I absolutely stand by championing such a standard module.
then I stop here waiting for other opinions about championing an Emitter
mixin/module/constructor in core.
best regards
On Wed, Jul 10, 2013 at 9:31 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
On Wed, Jul 10, 2013 at 6:16 PM, Rick Waldron waldron.r...@gmail.comwrote:
I absolutely stand by championing such a standard module.
then I stop here waiting for other opinions about championing an
On Jul 10, 2013, at 6:06 PM, Sam Tobin-Hochstadt wrote:
On Wed, Jul 10, 2013 at 8:02 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jul 10, 2013, at 4:40 PM, Sam Tobin-Hochstadt wrote:
On Wed, Jul 10, 2013 at 7:24 PM, Rick Waldron waldron.r...@gmail.com
wrote:
It gets created
On Wed, Jul 10, 2013 at 10:12 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jul 10, 2013, at 6:06 PM, Sam Tobin-Hochstadt wrote:
On Wed, Jul 10, 2013 at 8:02 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jul 10, 2013, at 4:40 PM, Sam Tobin-Hochstadt wrote:
On Wed, Jul 10,
On Jul 10, 2013 3:49 PM, Erik Arvidsson erik.arvids...@gmail.com wrote:
Jonas, DOM never throws DOMError. DOMErrors are used for other error
mechanisms, such as callbacks. [1]
Indeed. But this is one of the things I'm trying to fix. It seems very
silly that the DOM defines two classes of error
oh well ... I've missed the part when you guys decided that inherited
defaults are useless as properties ... :-/
as you said, inconvenient, and not only this case ... also good to know ^_^
On Wed, Jul 10, 2013 at 4:56 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Jul 10, 2013, at 4:32
I see [1] that arrow function syntax got specification state.
The problem with this construction: it's the only feature in ES syntax
so far that
requires compiler to use full AST implementation at compilation phase.
Consider this:
var val1 = 1;
var val2 = 2;
var sum1 = (val1, val2) + 1; //
On Jul 10, 2013, at 9:39 PM, Andrew Fedoniouk wrote:
I see [1] that arrow function syntax got specification state.
so, you should probably look at the relevant parts of the draft specification
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-5.1.4
68 matches
Mail list logo
