I've ported a few old fashioned callback code bases to async/await +
Promises in the last year or so.
When doing performance analysis and profiling I've noticed a significant
negative impact of Promise / async / await in that it adds micro tasks to
the queue.
Previously there was a different
But, I would pick one or the other over one with multiple personalities
This is a good mentality to have. Consider picking the one that allows the
other one to be implemented in user land.
This would allow both parties to benefit from the integrated tooling
performance boosts of it being a
What are the use cases for things like 'isGenerator'. When and why would
you need to know that an object upon which you are going to invoke the
Iterator interface was/wasn't implemented by a generator.
[`co`][1] is a library similar to Task.js that allows you to use ES6
generators as async /
Bacon's equivalent of EventStreamResolver.push() returns Bacon.noMore
when it finds that the number of listeners has gone to 0.
It should also be noted that streams2 in node return `false` from `push()`
when the stream is full.
Generally returning a value from `push()` as some kind of message
Would it help to split the sugar and combinator from the actual stream
interface?
```
callback StreamInit = void (StreamResolver resolver);
callback AnyCallback = any (optional any value);
[Constructor(StreamInit init)]
interface Stream {
Stream listen(optional AnyCallback? listenCB = null,
...@gmail.comwrote:
On Mon, Apr 15, 2013 at 4:24 PM, Jake Verbaten rayn...@gmail.com wrote:
Would it help to split the sugar and combinator from the actual stream
interface?
```
callback StreamInit = void (StreamResolver resolver);
callback AnyCallback = any (optional any value
So one thing that is confusing is that `next()` has an API that looks like
the stream is a pull stream. A pull stream means that you call next()
and it will give you the next value when it has it. This type of stream
generally buffers values internally and only gives you them when you pull
them
This API looks good. I've written a similar data binder and it's nice to
be able to have this functionality natively
The only thing missing is the ability to observe a single property of an
object rather then all properties.
On Tue, Jul 17, 2012 at 4:49 PM, Erik Arvidsson
Most of the time the purpose of deep cloning objects is deep cloning data
structures.
It's been discussed that generically deep cloning proxies, privates and
functions is a non-trivial problem.
However it would be of value to have a mechanism to deep clone anything
that would be valid JSON
On Sun, Jan 22, 2012 at 8:29 PM, Rick Waldron waldron.r...@gmail.comwrote:
Potential issues
- subset of JSON is too restricted to be useful
This alone seems like a deal-breaker/non-starter. How would you copy
methods? Forgetting about cyclic reference exceptions for a moment:
The idea
The idea here is that methods do not belong in data structures (clone
should be to efficiently clone data).
This is already too much unfortunate restriction.
What about calculated get properties:
var o = {
... get foo() {
... return foo;
... }
... },
... clone =
However, I am confused by the module.exports = ... part of your
boilerplate. The main CommonJS wiki seems down at the moment, but looking
at http://wiki.commonjs.org.mirrors.page.ca/articles/m/o/d/Modules.html
on the mirror site, I could not find any support for this idiom. The
closest I
Do we have a similar list for the features in chromium that are enabled
through the harmony flag? ( http://codereview.chromium.org/9008031 )
On Sun, Dec 25, 2011 at 9:31 AM, Axel Rauschmayer a...@rauschma.de wrote:
Is there a list somewhere of ECMAScript.next features that have already
been
First, if obj already has a non-configurable property 'a', this will
throw
I don't think object extension on a non configurable properties should be a
no op.
Your basically saying extend obj with { a: 1 } unless doing so would throw
an error, in which case fail silently
Personally I don't like
Current proposal would turn a configurable non-writable property into a
writable property which is not a silent error, but rather a big mistake.
If that is the case then I agree that would be bad. Whether we want to
throw an error or silently do a no-op is another discussion.
Given that
[snip]
let Point = class {
x: 0, //not really needed unless defining an object exemplar
y: 0,
new(x,y) {
this.x = x;
this.y=y;
}
};
Yes this is better, could we go one step further and allow for
Point.new(1,2)
to work instead of new Point(1,2).
If we just
Currently in ES5 strict mode the value of `this` is `undefined` by default.
function foo() {
return this;
}
foo(); // undefined
function foo() {
return (function () {
return this;
}());
}
foo.call(o); // undefined
Since the default value of `this` is always undefined, the `var that
On Fri, Nov 18, 2011 at 9:30 PM, Axel Rauschmayer a...@rauschma.de wrote:
What if we changed the value of `this` inside local function
declarations to be the value of this in the outer function.
I’d love this to work!
Alas, the value of `this` has to be determined dynamically. Mark Miller
5 Let *proto* be the value of the [[Prototype]] internal property of *obj*.
6 Return the result of evaluating this algorithm using the value of *proto* as
the value of *UnaryExpression*
*
*
What is the point of calling class recursively on the [[Prototype]] if the
object does not have constructor
On Thu, Nov 17, 2011 at 11:39 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 17, 2011, at 3:31 PM, Allen Wirfs-Brock wrote:
We can debate whether Default Constructors should do a:
if (super.constructor isnt Object) super.constructor()
but that is a more basic question about
Anyway, once again, the main point I wanted to note, is that we _already_
may have more-less good classes via libs with more-less acceptable
convenient super-calls. The standardized version should be better that all
the libs. I.e.: (1) not to have the issue you describe and (2) which IMO
Even with adding properties to objects (which is a no-no for ES.next),
dynamic super is never particularly elegant. This was the best solution I
could come up with and it’s not pretty: https://gist.github.com/1331748
If we could get away with manipulating the prototype chain at run time then
*UnaryExpression* :
*class* *UnaryExpression*
...
The semantics are:
1. if *UnaryExpression* is undefined or null, return the value of *
UnaryExpression*.
2. Let *obj* be ToObject(*UnaryExpression*)
3. Return the result of calling the [[Get]] internal method of
The whole concept is great.
What class does for the JS community is give everyone a standardized way to
write classes. The simplest way to have a class is to call
ObjectLiteral.constructor and that's exactly what this class syntax does.
This also means that it's very easy to adapt to using this.
Neither of them are fit for standardization. Selfish and Prototype are
both incapable of correctly deep copying arrays or objects,
Why does it matter that they don't deep copy? Deep copying is a difficult
problem that needs to be standardized separately. I've personally avoided
deep copying
Should `extend' copy all the properties? Only the own properties? I feel
`own' properties make more sense.
I agree own makes more sense, we also want to specify whether we want to
extend enumerable properties. Your example does not.
- Defining new objects that extends on the
However having a deep copy mechanism that works without obscure edge-cases
would be great.
Can you be specific? What obscure edge cases have you previously
encountered?
I don't have a list at hand, last time we talked about what it means to
deep copy an arbitary ES-next structure we ran
On Sun, Nov 13, 2011 at 4:51 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Nov 13, 2011, at 11:03 AM, Jake Verbaten rayn...@gmail.com wrote:
However having a deep copy mechanism that works without obscure edge-cases
would be great.
Can you be specific? What obscure edge cases have you
Let's argue about specifics or we'll get nowhere. Do you think Irakli's
selfish.js extend (
https://github.com/Gozala/selfish/blob/master/selfish.js) is the way to
go, or Prototype's quite different form?
I'd personally prefer Prototype's extend because it actually extends an
object
In es-next we should be able to subclass an array
function createArraySubclass(proto, ...values) {
return proto | [...values];
}
However when we call `instanceOfSubArray.filter(...)` this method returns a
new Array rather then a new SubArray.
It would seem frustrating to have to overwrite
The only value prototype inheritance gives is the fact you can change the
prototype and changes are reflected.
If you do not want that feature then use mixins.
On Thu, Nov 10, 2011 at 4:56 PM, Andreas Rossberg rossb...@google.comwrote:
I wholeheartedly agree that mixin composition is superior
Whats wrong with enumeration over own properties?
Object.keys() gets all enumerable own properties in a for .. in loop.
for .. in gets all enumerable properties in prototype chains.
I personally think it's bad practice to have code that enumerates over
properties in the prototype chain. I can't
You shouldnt store properties on the prototype chain like that. Your
abusing Object.create as a shallow copy. Use a real shallow copy method.
On Nov 8, 2011 7:07 PM, Felipe Gasper fel...@felipegasper.com wrote:
On 11/8/11 12:37 PM, Axel Rauschmayer wrote: What’s the use case?
I thought I gave
On Tue, Nov 8, 2011 at 11:36 PM, Brendan Eich bren...@mozilla.com wrote:
Ignoring performance, a lot of stylish JS hackers use
Object.keys(o).forEach. How many run into the wrong |this|
(arguments/break/continue/return)? Not clear. Something to study.
/be
I personally use `Object.keys()`
AM, Quildreen Motta quildr...@gmail.com wrote:
On 08/11/11 23:59, Jake Verbaten wrote:
However on average a lot more people will use for ... in with
hasOwnProperty because ES5 environments are rare and a lot of people avoid
the ES5-shim
Do you mean `rare' as in they have to work
I like this one mainly for the line
class declarations and object literals should have the same features
However if they have the same features then why bother with class at all.
Why not just have
let Monster = Being | { ... }
This way we don't introduce the class keyword which is confusing
I don't think I've ever heard an active JavaScript developer, who has
been programming in JavaScript longer than 6 months, ask for private class
or instance variables.
Your own code:
https://github.com/mikeal/npmjs.org/commit/c0d9cc77e79504b9a7c23b4fac735dde97444054#L3R10
Line 35, you
Why isn't the |super| lookup-point |this.getPrototypeOf()|
Assume |super| is |this.getPrototypeOf()|
Let F be a class, let f be an instance of the class.
inside f you have access to a method defined on F.
If you call a method defined on F from f and that method calls super, you
would be
On Sun, Oct 30, 2011 at 11:45 AM, Rick Waldron waldron.r...@gmail.comwrote:
On Oct 30, 2011, at 5:58 AM, David Bruant bruan...@gmail.com wrote:
Le 30/10/2011 02:35, Quildreen Motta a écrit :
(...)
Are we overthinking classes?
Perhaps the reason for all this thinking about classes
the only possible hazard that is left is function exemplar code trying to
access ObjectExamplar.prototype
Could you illustrate where a function exemplar may try to access an
ObjectExemplar.prototype property?
Would this be old code that accepts an exemplar as input but expects it to
be a
Whilst on the topic of object literal extensions, did we make any progress
on supporting what allen calls
exemplarshttps://mail.mozilla.org/pipermail/es-discuss/2011-October/017369.html
?
let Employee = Person | {
constructor(name, title) {
super(name);
this.title = title;
},
Personally I'd ask whether there is a good reason to have class properties
on the constructor.
//class (ie, constructor) properties
You could have them on the prototype instead and then you can access these
class properties through all your instances.
Also you could just re-order the assignment
class-specific constants such as Point.ZERO.
Why can't this be on the prototype? Why do we even pass the constructor
function around as an object?
I agree we need a better way of writing this, I think the flaw lies in
passing constructor functions around everywhere.
I believe the community just says A inherits B even thought they mean that
A.prototype.[[Prototype]] == B.prototype.
On Oct 23, 2011 7:24 PM, Axel Rauschmayer a...@rauschma.de wrote:
- What about primitives?Are there primitive types and object types? Is
the union of the two calle...
Yes that is
As for xmlhttprequest not working, I get
DOM object constructor cannot be called as a function
This basically means xmlhttprequest is a host object which does not want to
behave normally. Maybe with some very subtle tricks you can get it to
subclass but I recommend not subclassing host objects.
/
Address: 29 Rue Saint-Georges, 75009 Paris, France http://goo.gl/maps/3CHu
On Tuesday, 2011-10-11 at 20:53 , Jake Verbaten wrote:
is there any kind of proposal for syntax that is like : var proto =
{method: function(...
___
es-discuss mailing list
On Mon, Oct 17, 2011 at 11:19 AM, Axel Rauschmayer a...@rauschma.de wrote:
[cc-ing es-discuss]
On Oct 17, 2011, at 11:31 , Jake Verbaten wrote:
If we could find a way to mark methods as constructors (e.g. by prefixing
an @, but we are heading into Grawlix territory then), we could do
An inner function is a function declaration or expression inside a function.
Currently the default value of this is either the global object or undefined
for strict mode. (When invoked normally).
Would it be possible to have the value of this default to the value of this
in the outer function,
) {
// here, this is o2
f( );
}
};
o1.m1();
I'm quite sure some people would expect one behavior and others would
expect the other one... but it is sure that would be a source of
hard-to-track bugs.
On Sat, Oct 15, 2011 at 2:54 PM, Jake Verbaten rayn...@gmail.com wrote:
An inner function
I agree having two types of examplers is sensible.
For examples sake let fExemplar be an exemplar constructed with new
Function and les oExemplar be the other one.
Now, I'm worried about magically making
fExemplar | oExemplar
work, would oExemplar have fExemplar or fExemplar.prototype in it's
The difference is that object.extend returns objects where as object.make
returns things with the same type as the second operand.
So object.extend (obj, someFunction) is easy.
where as object.make(obj, someFunction) returns a function. Now clearly its
a new function so it doesnt share closure
To expand on inheritance operator, I would treat es:h classes as declarative
sugar for exemplars. Therefore it would make sense to have the extends
keyword work on exemplars.
We could use oExemplar extends fExemplar and have that make inheritance work
as expected
On Oct 14, 2011 8:38 AM, Jake
Why have this be part of the language? You can write code by contract
libraries (I have one : https://github.com/Raynos/contract ). And you can
write a javascript to javascript compiler that parses jsDoc comments and
generates code that interacts with a code by contract library automatically.
Yes
On Fri, Oct 14, 2011 at 2:44 PM, Peter Dekkers pe...@jbaron.com wrote:
True of course that JS is a dynamic language by nature and it is not
my suggestion/intention to make it more typed. I strongly believe the
prototype part of JS is one of its main selling points.
However a function expects
On Fri, Oct 14, 2011 at 2:59 PM, Quildreen Motta quildr...@gmail.comwrote:
2011/10/14 Brendan Eich bren...@mozilla.com
On Oct 14, 2011, at 9:25 AM, Quildreen Motta wrote:
I think my major pet-peeve against using strict types for contracts is:
1.) JS is not a statically typed language,
I would like to argue the other side. For my coffeescript vs javascript is
big enough to be happy. I am happy writing javascript and coffeescript
irritates me to no end.
On Fri, Oct 14, 2011 at 5:50 PM, Jorge jo...@jorgechamorro.com wrote:
On 13/10/2011, at 19:05, Russell Leggett wrote:
Is
On Fri, Oct 14, 2011 at 5:54 PM, John J Barton
johnjbar...@johnjbarton.comwrote:
On Thu, Oct 13, 2011 at 4:14 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
Let me take a crack at tying to tie together all the pieces we have been
talking about.
Allen, I really appreciate your
| fExemplar, where oObject looks like an exemplar but
isnt used as one.
If you can make it just work without leaking then that would be great
On Oct 14, 2011 7:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Oct 14, 2011, at 12:38 AM, Jake Verbaten wrote: I agree having two
types of examplers
Whilst mentioning Object.createSimple, is there any plan for having matching
functions for all this declaritive syntax?
On Oct 13, 2011 8:17 AM, Jay Skeer j...@seanet.com wrote:
**
On 10/12/2011 07:57 PM, John J Barton wrote: On Wed, Oct 12, 2011 at
5:52 PM, Allen Wirfs-Brock ...
I agree, and
This expresses an issue I have as well. the es:harmony proposal for classes
just vaguely states it desugars into es5 things.
We may need more clarification on exactly what it desugars to and how you
can interact with a class object outside the declarative class
expressions.
On Oct 13, 2011 1:03
As for shooting down the useful ness of - I personally find that one line
functions are ugly.
So:
someObject.method = function () { doSomething(...); }
is ugly because it doesn't follow my `{ \n` convention for readability and
code organization.
However I'd be happy to make an exception in my
, 2011 at 5:08 PM, Brendan Eich bren...@mozilla.com wrote:
On Oct 13, 2011, at 3:59 AM, Jake Verbaten wrote:
Whilst mentioning Object.createSimple, is there any plan for having
matching functions for all this declaritive syntax?
We do not want functions that mutate the [[Prototype]] internal
One of the reasons traceur is not suitable is that it's a product of google
and thus not neutral.
I've actually asked traceur whether they intent to become a full es harmony
compliant transpiler but there was no response.
And another reason would be that it currently implements some strawmans
On Tue, Oct 11, 2011 at 7:40 PM, John J Barton
johnjbar...@johnjbarton.comwrote:
On Tue, Oct 11, 2011 at 11:14 AM, Brendan Eich bren...@mozilla.comwrote:
On Oct 11, 2011, at 1:47 PM, John J Barton wrote:
On Tue, Oct 11, 2011 at 10:08 AM, Brendan Eich bren...@mozilla.comwrote:
On Oct 11,
On Tue, Oct 11, 2011 at 8:11 PM, Axel Rauschmayer a...@rauschma.de wrote:
*From: *Jake Verbaten rayn...@gmail.com
*Subject: **new Object*
*Date: *October 11, 2011 20:53:58 GMT+02:00
*To: *es-discuss es-discuss@mozilla.org
is there any kind of proposal for syntax that is like:
[...]
var
On Tue, Oct 11, 2011 at 8:58 PM, Axel Rauschmayer a...@rauschma.de wrote:
I dont think having both new Object and new Function in the language
will cause any conflicts. It's the same as claiming that having both
declarative class and new Function would cause confusion.
I wouldn’t mind
Yes the prototypes are still there. But that means im just using es3
constructs. Es:harmony class literals only offer declarative sugar.
I'm not proposing we change any of the existing Class.prototype.* code. I
just propose that rather then throwing an error on new Object we make it
work.
This
alternatives for those as well. This might
warrant another thread.
On Oct 11, 2011 11:12 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Oct 11, 2011, at 1:46 PM, Jake Verbaten wrote: Yes the prototypes are
still there. But that m...
I agree that new object would be a useful feature for ES
Point.zero = function () {
return (new Point).{ x: 0, y: 0 };
}
why are factory methods special? they are just methods.
On Oct 11, 2011 11:26 PM, Axel Rauschmayer a...@rauschma.de wrote:
I absolutely love it for its conceptual beauty, but the primary goal should
be to establish a single
which might return an instance of any
subclass of Expression, depending on what is parsed – a literal, a binary
operator, etc.). But maybe that should just be a function, e.g.
parseExpression().
On Oct 12, 2011, at 0:29 , Jake Verbaten wrote: Point.zero = function () {
return (new Poi
...@switchb.org wrote:
On Oct 11, 2011, at 18:29, Jake Verbaten wrote: Point.zero = function () {
return (new Point)...
I agree with things should be just methods, but this particular pattern
doesn't work for always-frozen types.
--
Kevin Reid http://switchb.org
Object.create does indeed require propertydescriptors as the second
argument. This is the easiest way to send meta-data like read-only.
However it's verbose and the defaults are restrictive. I've written a small
library (github.com/Raynos/pd) to make it less verbose, you might find it
useful.
There is no standardized way to create a new function with a prototype which
is not Function.prototype.
I propose Function.create
/*
Creates a new function whose prototype is proto.
The function body is the same as the function fbody.
The hash of propertydescriptors props
On Sat, Sep 24, 2011 at 5:03 PM, David Bruant david.bru...@labri.fr wrote:
- Show quoted text -
I defiantly like this `|` operator. I would happily have this instead.
I'm a big fan of the proto operator proposal, however, as raised
previously this operator relies on the object being created
var f = function() { return this; }
var g = f.bind(???);
g.apply({ foo: bar }).foo // expect bar
Function.prototype.bind set's the thisArg to a certain value. Is there any
way to leave it flexible to be overwritten using `.call` and `.apply` later
on?
Is there any ES:Harmony/strawman proposal
75 matches
Mail list logo
