With the upcoming (but separate) private fields proposal, the example
evolves from:
class IncreasingCounter {
_count = 0;
get value() {
return this._count;
}
increment() {
this._count++;
}
}
...into:
class IncreasingCounter {
#count = 0;
get value() {
return this.#count;
}
increment() {
this.#count++;
}
}
The example makes more sense in the context of that progression. (This is how
we explained the class features at Google I/O
<https://www.youtube.com/watch?v=mIWCLOftfRw&t=36m27s>.)
On Tue, Oct 23, 2018 at 1:11 PM <[email protected]> wrote:
> As exciting as this is, can anyone please explain why a feature called
> "public field" is being announced with properties prefixed by an
> underscore, which historically means "protected" or, to some extend,
> private property, in JavaScript-land ?
>
> This is a question specially for those that might decide to write some
> blog-post about this new feature: please don't use `_counter` or, if you
> like that, please explain that using `_` is just an author convention and
> it has nothing to do with the public field proposal itself.
>
> Thanks for your understating and for considering a better divulgation of
> such welcome news.
>
> Best Regards
>
> On Wednesday, October 17, 2018 at 9:47:04 AM UTC+2, Sathya Gunasekaran
> wrote:
>>
>> Contact Emails:
>> [email protected]
>>
>> Spec:
>> https://github.com/tc39/proposal-class-fields
>> https://tc39.github.io/proposal-static-class-features/
>>
>> The linked proposal includes private fields, but this intent to ship
>> is only for public instance and static fields, not private fields.
>>
>> Summary:
>> Public class fields build upon the class syntax introduced in ES2015
>> by allowing declaration of both instance and static public fields.
>>
>> The following ES2015 syntax:
>>
>> class IncreasingCounter {
>> constructor() {
>> this._count = 0;
>> }
>> get value() {
>> return this._count;
>> }
>> increment() {
>> this._count++;
>> }
>> }
>>
>> can now be rewritten as:
>>
>> class IncreasingCounter {
>> _count = 0;
>>
>> get value() {
>> return this._count;
>> }
>> increment() {
>> this._count++;
>> }
>> }
>>
>> Interoperability and compatibility risk:
>> This syntax was previously a Syntax error, therefore there is very low
>> web compat risk.
>>
>> There's one very minor spec non compliance in the current
>> implementation around the class name during static field
>> initialization (https://github.com/tc39/proposal-class-fields/issues/85)
>> which needs to be discussed at the next TC39 meeting.
>>
>> Firefox: In development (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1499448)
>> Safari: In development (https://bugs.webkit.org/show_bug.cgi?id=174212)
>> Edge: No signal
>>
>> Is this feature fully tested?
>> V8 tests (mjsunit, cctest/test-parsing) as well as all test262 tests
>> pass for this feature.
>>
>> Chromestatus entry:
>> https://www.chromestatus.com/feature/6001727933251584
>>
>> Requesting approval to ship?
>> Yes. Note that since this is a V8/JS feature, this post is just an FYI
>> to blink-dev — no signoff from Blink API owners is required.
>>
> --
> --
> v8-dev mailing list
> [email protected]
> http://groups.google.com/group/v8-dev
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups
"v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
