Thank you Brendan for picking this up!
Nozomu, Brendan, please let me know if I can be of any help.
Sebastian
On 8 June 2015 at 18:47, Brendan Eich bren...@mozilla.org wrote:
I will do it if no one else steps up by 10pm tonight PDT.
Thank you to Nozomu Katō for writing it up!
/be
I like that syntax.
I wonder about the runtime semantics of it, though. (I know TypeHint
is a TODO, but…)
Is there any implication at runtime of a function that returns a String?
Is this:
```js
var point = {
x Number,
y Number
};
```
… the same as this?
```js
var point = {
x: Number(),
Alright first I'll say I'm using FF to test because FF supports proxies,
and I really don't know how to use Reflect and how it works yet. FF as well
does not support Reflect right now. Therefore I'll look into that.
So from [this source](
quick personal thoughts on this matter, leaving the named arguments part
beside (as it is looks kinda redundant/unnecessary effort that could wait)
We've been talking about types for long time in here and the good old
direction was *binary data* in the form of `StructType`
```js
const Point2D =
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-performpromiseall
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-performpromiseall
I’m wondering: Is it OK that PerformPromiseAll invokes `resolve()` via
`C.resolve()` (versus `this.resolve()`) with `C` determined via the
Le 9 juin 2015 à 07:58, Edwin Reynoso eor...@gmail.com a écrit :
**Or does someone know how to do what I'm trying to accomplish**
Maybe the following code goes in the direction of what you want?
```js
var people = new Proxy([new Person('Edwin', 'Reynoso'), new Person('That',
'Guy')], {
On Jun 9, 2015, at 1:57 AM, Andrea Giammarchi
andrea.giammar...@gmail.commailto:andrea.giammar...@gmail.com wrote:
quick personal thoughts on this matter, leaving the named arguments part beside
(as it is looks kinda redundant/unnecessary effort that could wait)
We've been talking about types
On Tue, Jun 9, 2015 at 8:30 AM, Luke Scott l...@webconnex.com wrote:
[...]
It currently uses `=` to define properties. And there is some debate
whether or not properties should be initialized in the constructor or be on
the prototype.
There is no debate about whether per-instance state (of
On Jun 9, 2015, at 1:21 AM, Thaddee Tyl thaddee@gmail.com wrote:
I like that syntax.
I wonder about the runtime semantics of it, though. (I know TypeHint
is a TODO, but…)
Is there any implication at runtime of a function that returns a String?
Is this:
```js
var point = {
x
On Tue, Jun 9, 2015 at 11:11 AM, Mark S. Miller erig...@google.com wrote:
Ok, thanks for the example. I understand your rationale. This is what I
asked for but not what I was really looking for. Can we come up with an
example where class and species usefully differ where neither is Promise?
On Tue, Jun 9, 2015 at 3:44 AM, Edwin Reynoso eor...@gmail.com wrote:
Alright first I'll say I'm using FF to test because FF supports proxies, and
I really don't know how to use Reflect and how it works yet. FF as well does
not support Reflect right now. Therefore I'll look into that.
That's
It would help to have a concrete motivating example where the Promise
subclass were usefully distinct from the Promise subclass' species.
On Tue, Jun 9, 2015 at 7:30 AM, C. Scott Ananian ecmascr...@cscott.net
wrote:
`Promise.resolve` doesn't use the species pattern any more:
Allen Wirfs-Brock wrote on Tue, 9 Jun 2015, at 07:27:36 -0700:
Nozomu,
Also, please register as an Ecma TC39 non-member contributor by
following the steps described at
https://github.com/tc39/ecma262#contributing-new-proposals
I just did. Thank you for telling me that.
Nozomu
`Promise.resolve` doesn't use the species pattern any more:
https://esdiscuss.org/topic/fixing-promise-resolve
The rationale was that `resolve` is more like a constructor than a mutator.
I don't have a strong opinion about `Promise.all`, but I think perhaps it
would be better if none of the
Mark: I outlined two of these use cases in
https://esdiscuss.org/topic/subclassing-es6-objects-with-es5-syntax#content-50
One is `WeakPromise` which is a promise holding a weak reference to its
resolved value. This is the closest analogy with the canonical Smalltalk
motivating example for
On Jun 9, 2015, at 6:18 AM, Nozomu Katō wrote:
On 8 June 2015 at 18:47, Brendan Eich wrote:
I will do it if no one else steps up by 10pm tonight PDT.
I thank you very much indeed for taking this proposal on. I am very
relieved!
Nozomu,
Also, please register as an Ecma TC39 non-member
On Jun 9, 2015, at 7:30 AM, C. Scott Ananian wrote:
`Promise.resolve` doesn't use the species pattern any more:
https://esdiscuss.org/topic/fixing-promise-resolve
The rationale was that `resolve` is more like a constructor than a mutator.
I don't have a strong opinion about `Promise.all`,
On Tue, Jun 9, 2015 at 7:58 AM, C. Scott Ananian ecmascr...@cscott.net
wrote:
Mark: I outlined two of these use cases in
https://esdiscuss.org/topic/subclassing-es6-objects-with-es5-syntax#content-50
One is `WeakPromise` which is a promise holding a weak reference to its
resolved value.
Syntax for putting properties on the prototype was long-ago rejected
because of footgun potential.
Correction: *data* properties. : )
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
TypeScript was just an example, but being class a different Syntax beast
than just prototype (right?) why would that be bad? It will be indeed
not-unexpected as Kevin mentioned later on.
Using classes thinking prototypes feel something developers won't do
(specially new comers) so TypeScript
On Tue, Jun 9, 2015 at 9:35 AM, C. Scott Ananian ecmascr...@cscott.net
wrote:
Promise subclassing is super useful. `prfun` uses it extensively: first
to override the global `Promise` to avoid polluting the global namespace,
and then secondly to implement features like `Promise#bind`. I've
I know I'm being picky here, but if timeout-ness is not intended to
propagate, which seems sensible, then why would I ever want to invent a
TimeoutPromise subclass rather than using a combinator like delay or race
on a plain Promise?
___
es-discuss
Why can't we use proxy or a new global object call StrictType, or a new
property call definePropertiesType on the global Object
Than we could use the syntax style of the language :
Object.definePropertiesType(object,{
age:{type:Number},
name:{type:String},
height:{type:Float}
});
All of
On Tue, Jun 9, 2015 at 12:38 PM, Mark S. Miller erig...@google.com wrote:
Do you ever test that the object returned by `Promise#timeout(n)` is
something other than a plain promise?
Responded on the other thread.
Let's keep this one focused on: do we need to tweak the definitions of
On Tue, Jun 9, 2015 at 9:13 AM, Mark S. Miller erig...@google.com wrote:
My larger theme here is that I think promise subclassing is way overrated.
OO programmers tend to treat subclassing according to the everything is a
hammer rule. Promises do need an extension point, such as the old
Mark, properties on the prototype are in TypeScript, and probably every
other OOP based language. Defaults can be easily defined as such, i.e.
```js
class Person { name = 'anonymous'; age = 0; }
```
Not only, defaults could be optimized upfront by parsers without needing to
infer or do extra
My larger theme here is that I think promise subclassing is way overrated.
OO programmers tend to treat subclassing according to the everything is a
hammer rule. Promises do need an extension point, such as the old makeFar
and makeRemote proposals explained at
Mark: The `prfun` library in fact uses `Promise#timeout(n)` instead of a
`TimeoutPromise` subclass. But this is really a language-design question.
You might as well ask why we have `WeakMap()` as a constructor instead of
using `Map#weak()` or `weakmapify(map)`. The fundamental reason is so you
On Tue, Jun 9, 2015 at 9:13 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Mark, properties on the prototype are in TypeScript, and probably every
other OOP based language. Defaults can be easily defined as such, i.e.
```js
class Person { name = 'anonymous'; age = 0; }
```
At
Anyway, I'm curious to know why do you think getters and setters are OK
and properties are not. I don't see any technical difference, specially
considering get/set for lazy property computation/assignment through the
prototype getter anyway.
Syntax for putting properties on the prototype
Promise subclassing is super useful. `prfun` uses it extensively: first to
override the global `Promise` to avoid polluting the global namespace, and
then secondly to implement features like `Promise#bind`. I've also used it
experimentally to implement functional promises (with a `Promise#chain`
On Tue, Jun 9, 2015 at 9:29 AM, C. Scott Ananian ecmascr...@cscott.net
wrote:
Mark: The `prfun` library in fact uses `Promise#timeout(n)` instead of a
`TimeoutPromise` subclass. But this is really a language-design question.
You might as well ask why we have `WeakMap()` as a constructor
On Tue, Jun 9, 2015 at 12:38 PM, Mark S. Miller erig...@google.com wrote:
On Tue, Jun 9, 2015 at 9:29 AM, C. Scott Ananian ecmascr...@cscott.net
wrote:
Mark: The `prfun` library in fact uses `Promise#timeout(n)` instead of a
`TimeoutPromise` subclass. But this is really a language-design
Also static properties are on __proto__, so it seems a bit strange that
instance properties would not also be on .prototype. Somewhat of a
consistency issue I suppose.
Methods declared as static in ES6 are defined on the constructor itself.
Apparently, static data properties in TS are
On Jun 9, 2015, at 9:23 AM, Kevin Smith
zenpars...@gmail.commailto:zenpars...@gmail.com wrote:
Anyway, I'm curious to know why do you think getters and setters are OK and
properties are not. I don't see any technical difference, specially considering
get/set for lazy property
What about the interaction between q and r in .then, that I mentioned in my
previous email? That's the reason I changed my mind and now think we need
an extension mechanism besides subclassing in order to make pipelining
work. Note: it needs to work even if p is a plain promise. It is only q
that
I think that Promise pipelining works just fine -- you just have to
implement it inside Promise#get, Promise#put, etc.
```
// This is already in prfun
Promise.get = function(fieldname) { return this.then(function(o) { return
o[fieldname]; }); };
// This comes with your RPC mechanism
how about introducing a well known concept in JS as `own` ?
```js
class Person {
static name String: A person name
own name String: anonymous
own items Array: []
constructor(name) {
if (name) this.name = name;
}
}
var anon = new Person,
me = new Person('AG');
anon.items;
how about introducing a well known concept in JS as `own` ?
```js
class Person {
static name String: A person name
own name String: anonymous
own items Array: []
Let's take a step back and ask: what's the motivation for having these
property declarations and initializers outside
Inline replies
On Tue, Jun 9, 2015 at 9:01 PM, Kevin Smith zenpars...@gmail.com wrote:
Let's take a step back and ask: what's the motivation for having these
property declarations and initializers outside of the constructor?
The same motivation of having `static` properties definition in
I don't understand your answer. p and r are plain promises. They must be
because they exist before q does. q is the first remote promise in this
scenario. How does resolving r to q leave r unsettled but give q access to
the messages buffered (and to be buffered) in r?
I think the answer must
On Tue, Jun 9, 2015 at 3:45 PM, Mark Miller erig...@gmail.com wrote:
I don't understand your answer. p and r are plain promises. They must be
because they exist before q does. q is the first remote promise in this
scenario. How does resolving r to q leave r unsettled but give q access to
the
Is there any way to find out how this works *now*? I can’t find the May 2015
meeting notes, either.
Do all static Promise methods now just use `this` (e.g. `Promise.all()` →
`this.promiseResolve(···)`)? Or only `Promise.resolve()`?
Thanks!
Axel
On 02 Jun 2015, at 23:28, Allen Wirfs-Brock
This thread is a cool example of why this list is still do important. +1 to
all of it!
On Jun 9, 2015 4:20 AM, Sebastian Zartner sebastianzart...@gmail.com
wrote:
Thank you Brendan for picking this up!
Nozomu, Brendan, please let me know if I can be of any help.
Sebastian
On 8 June 2015 at
On 8 June 2015 at 18:47, Brendan Eich wrote:
I will do it if no one else steps up by 10pm tonight PDT.
I thank you very much indeed for taking this proposal on. I am very
relieved!
Sebastian Zartner wrote on Tue, 9 Jun 2015, at 10:20:00 +0200:
Nozomu, Brendan, please let me know if I can be
45 matches
Mail list logo
