FWIW, individual parts of the "grid" don't all have to ship at the
same time. Private instance fields are farther along than private
static fields, for instance, and private methods are being considered
separately from private fields. Another example is with async
functions beating async
*An errata in my code*
The getter is mutating the object with a enumerable property, so
consecutives invocations of JSON.stringify will result different from
the first call (if the property is yet not initialized). The current
problem is:
```js
JSON.stringify(foo) // Returns "{"bar":3}"
// After
I agree the main proposal is long and complex, but this kind of addition
could be designed with little effort to "fall out of the grid", since it
has so much in common with classes already (properties, getters/setters,
methods). The main question is with properties, but those are easy to just
On June 27, 2018 09:23, kai zhu wrote:
> what would happen if you tried to JSON.stringify foo? a core-value of
javascript to industry is as an idiot-proof/least-surprise language for
serializing json-data across browser <-> server. junior-programmers who
naively employ hard-to-serialize things
If you're wanting to propose new places for decorators, you'd have much
better luck here: https://github.com/tc39/proposal-decorators
I do agree this is an obvious place for a decorator, and it is probably the
ideal way of specifying it for object properties, but your larger proposal
of adding
> What it's doesn't cover (and in my opinion should be the focus of a new
> proposal) is Decorators for literal objects. Something like the code below is
> yet not proposed:
>
> ``` js
> const foo = {
> @lazy bar: 3,
> };
> ```
what would happen if you tried to JSON.stringify foo? a
BTW, I proposed similar (lazy values) 9 months ago [1], and it's been
on the list plenty of times [2]. I'd personally *love* to see it
happen, but I find it not very likely it'd make it, especially as a
property (since decorators can rectify that).
[1]: https://esdiscuss.org/topic/lazy-evaluation
Yes, something is getting done about decorators.
https://github.com/tc39/agendas/pull/398
On Tue, Jun 12, 2018 at 4:27 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> To me decorators are the answer to pretty much everything but for the last
> year I've seen zero progress on what
To me decorators are the answer to pretty much everything but for the last
year I've seen zero progress on what seems to be a forever Stage 2
proposal: https://github.com/tc39/proposals#stage-2
Is there anything anyone can do to speed up adoption/implementation of that
proposal?
On Tue, Jun 12,
I don't think a new keyword is the right path here. For classes lazy fields
can easily be implemented via decorators in the last proposal[1] (also,
Groovy has previous work implementing a `@Lazy` annotation[2] with AST
transformations for the same use case). In code something like:
``` js
const
The problem here is that if lazy field and lazy getter are indeed
different beast, one should be able to discriminate the two inside the
property descriptor.
So maybe
// replaces with getter on first access
{lazy: producerFn, get: null, ...}
// replaces with value on first access
FWIW, I think to keep it simple `lazy: true` would be enough for the time
being.
Having the new descriptor inside the descriptor seems a bit over
engineering at this point, imo, but having a field already won't exclude,
in the feature, the ability to improve that field (similar way
On June 12, 2018 2:37:05 PM GMT+02:00, he...@mailbox.sk wrote:
>Actually, by malleable I meant only configurable:true, so one can
>change it via Object.defineProp… api, I did not mean necessarily to
>define it as value.
>
>I have no strong opinion on what should be there after the first
>access,
Actually, by malleable I meant only configurable:true, so one can change it via
Object.defineProp… api, I did not mean necessarily to define it as value.
I have no strong opinion on what should be there after the first access, but it
boils down on how will it be exposed via
forgot about this:
> I think {get: getterFn, lazy: true, …} could work.
sort of, because descriptors can be only for properties or accessors, but
lazy + set, as accessor might look weird.
However, if I can dare bringing in another use case I have daily in my
code, I have a case for having a
On Tue, Jun 12, 2018 at 12:31 PM, Aadit M Shah
wrote:
> Classes in JavaScript don't allow assignments within the class body.
Hence,
> the following code is invalid:
>
> class Test {
> x = 123; // This throws an error.
> lazy random = this.x + Math.random(); // Similarly, this should be
>
On June 12, 2018 1:32:04 PM GMT+02:00, he...@mailbox.sk wrote:
>This autofreezing if the value sticks out out this philosophy of "
_of_ the value
>malleable unless specified otherwise".
___
es-discuss mailing list
es-discuss@mozilla.org
Okay, so my previous statement about field declarations in classes being
invalid was incorrect. I didn't see Andrea's link to the class field
declarations proposal[1]. Hence, from what I understand we're
considering the following syntax:
const zeros = { head: , lazy tail: this };
class Random {
> Why enforcing configurable false?
The fact the lazy getter is called getter, and the fact that a getter
cannot be assigned or the engine throws errors, as opposite of a non
configurable property that will silently ignore the assignment, makes me
think substituting a lazy getter with a fixed
On June 12, 2018 11:32:22 AM GMT+02:00, Aadit M Shah
wrote:
>Actually, from a parsing perspective I believe it shouldn't be too
>difficult to implement the `lazy name: expression` syntax. In
>addition, I'm not too keen on your `lazy name() { return expression;
>}` syntax because:
> 1. It's
Classes in JavaScript don't allow assignments within the class body.
Hence, the following code is invalid:
class Test {
x = 123; // This throws an error.
lazy random = this.x + Math.random(); // Similarly, this should
be invalid.}
Hence, the more I think about it the more it makes
On June 12, 2018 9:44:31 AM GMT+02:00, Andrea Giammarchi
wrote:
>My 2 cents,
>I use lazy getters since about ever and I'd love to have such syntax in
>place but I think there is room for some improvement / simplification
>in
>terms of syntax.
Yeah I find this better.
Also fixes the this
Actually, never mind. I've just realized this would work as well, and it's
clean enough.
```js
class Test {
x = 123;
lazy random = this.x + Math.random();
}
const test = {
x: 123,
lazy random: this.x + Math.random()
};
```
My only concern is if that class method is created N times per
it's not about being difficult, it's about compatibility with classes,
where getters are OK since ever. However, since classes fields are in Stage
3 [1] maybe it's OK to have:
```js
class Test {
x = 123;
lazy random = () => this.x + Math.random();
}
```
However, like you've noticed, while
Actually, from a parsing perspective I believe it shouldn't be too
difficult to implement the `lazy name: expression` syntax. In
addition, I'm not too keen on your `lazy name() { return expression;
}` syntax because:
1. It's more verbose.
2. It seems to me that it's no different than creating a
That is why I'm proposing to use a getter, you don't have to reason about
the context in `lazy fullname() { return this.firstName + ' ' +
this.lastName; }` and it still works with de-contextualized invokes such
`lazy random: () => Math.random()` as long as you transpile that as getter
calling the
When the getter lives on a prototype it would install the memoized value
on this using [[Define]]. This is the same way it would work in regular
lazy getters:
const defclass = prototype => {
const constructor = prototype.constructor;
constructor.prototype = prototype;
return
in case the counter proposal is not clear enough (apologies for that), this
should read simpler than that
```js
const take = (n, xs) => n === 0 ? null : xs && {
head: xs.head,
lazy tail() {
const value = take(n - 1, xs.tail);
Object.defineProperty(this, 'tail', {
* having an extra keyword ...
On Tue, Jun 12, 2018 at 9:44 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> My 2 cents,
> I use lazy getters since about ever and I'd love to have such syntax in
> place but I think there is room for some improvement / simplification in
> terms of
My 2 cents,
I use lazy getters since about ever and I'd love to have such syntax in
place but I think there is room for some improvement / simplification in
terms of syntax.
*## Keep it getish*
>From parsing perspective, introducing `lazy tail()` seems way simpler than
introducing `lazy tail:`
How would this work when the getter lives on a prototype? (like most
builtin getters) Would it install the memoized value on `this`, or on the
object that contains the getter? Would it use [[Set]] or [[Define]]?
On Tue, Jun 12, 2018 at 12:13 AM, Aadit M Shah
wrote:
> Hello TC39,
>
> I recently
Hello TC39,
I recently opened an issue[1] in the tc39/ecma262[2] repository,
proposing a new syntax for lazy getters, and I was directed to the
CONTRIBUTING[3] page which stated that I should start a conversation on
this mailing list.
So, my feature proposal is to have syntactic sugar for
32 matches
Mail list logo
