Intent to Ship: Public class fields

[Sathya Gunasekaran]

Contact Emails:
gsa...@chromium.org

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.

[Mathias Bynens]

LGTM

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMd%2BM7w_4-eJufKNB3gBzj2EsZUng0VD%3DmzbPmBr7q_-zn-yFw%40mail.gmail.com.

[PhistucK]

Are the specification and implementation compatible with the Babel based implementation/interpretation of the feature? After all, previously transpiled code could now be interpreted natively...

Unfortunately, this is also considered "Web compatibility".

☆PhistucK

[Sathya Gunasekaran]

On Wed, Oct 17, 2018 at 10:51 AM PhistucK <phis...@gmail.com> wrote:
>
> Are the specification and implementation compatible with the Babel based implementation/interpretation of the feature? After all, previously transpiled code could now be interpreted natively...
> Unfortunately, this is also considered "Web compatibility".
>

I filed several issues against Babel:
https://github.com/babel/babel/issues/6764
https://github.com/babel/babel/issues/6732
https://github.com/babel/babel/issues/6493
https://github.com/babel/babel/issues/6243
https://github.com/babel/babel/issues/6240
https://github.com/babel/babel/issues/6872

They mostly seem to be fixed which makes me optimistic that Babel is
spec compliant. If you find issues, please file bugs against Babel.

Thanks,
--Sathya

[Adam Klein]

LGTM. I'm super-excited about this shipping!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

[Daniel Ehrenberg]

Great work Sathya. I'm happy to see this shipping. I'll make sure we discuss the open spec issue at the next TC39 meeting. My understanding is that becoming spec-compliant would not be a very large change. I think it's fine to split out public and private fields like this--this split corresponds to the original factoring of the specs, anyway, and Blink frequently ships well-documented fractions of specifications. I'm looking forward to seeing an I2S for private fields soon.

Thanks,

Dan

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mathias Bynens]

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.)

On Tue, Oct 23, 2018 at 1:11 PM <andrea.g...@gmail.com> 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

--
--
v8-dev mailing list
v8-...@googlegroups.com
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 v8-dev+un...@googlegroups.com.

[andrea.g...@gmail.com]

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: