-
-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Class Fields (Stage 3) #12
Comments
dunno how much of an help this is, but I've been experimenting already with this and my conclusion is that, to represent the current proposal, each class needs it's own WeakMap. Examplesource class A {
#value = 1;
valueOf() {
return this.#value;
}
}
class B extends A {
#value = 2;
toString() {
return String(this.#value);
}
} pseudo target const privatesA = new WeakMap;
function A() {
privatesA.set(this, {__proto__: null, value: 1});
}
Object.defineProperties(
A.prototype,
{
valueOf: {
configurable: true,
writable: true,
value: function () {
return privatesA.get(this).value;
}
}
}
);
const privatesB = new WeakMap;
function B() {
A.call(this);
privatesB.set(this, {__proto__: null, value: 2});
}
Object.defineProperties(
Object.setPrototypeOf(
Object.setPrototypeOf(B, A).prototype,
A.prototype
),
{
constructor: {
configurable: true,
writable: true,
value: B
},
toString: {
configurable: true,
writable: true,
value: function () {
return String(privatesB.get(this).value);
}
}
}
); in that way |
Isn't that only the case if "value" is transformed to a string? I'd think you could use an in-scope constant - like a symbol or an object literal - and then it'd be unique and you could share one WeakMap for the entire file. |
I'm not sure I am following you ... the example has nothing to do with the |
I understand that you must use a WeakMap. I'm responding to "each class needs it's own WeakMap" - it seems like both class A and B could share the same WeakMap, since each "value" is a distinct PrivateName. |
A single |
It's not just a matter of implementation, it's a matter of standard. You cannot have shared WM between classes because private field #a accessed via an inherited method is NOT the same private field #a accessed by subclass method. Please understand the current proposal before premature optimizations |
It might be better to discuss this on the implementation PR than on this thread. I like the implementation strategy of that patch: In spec-compliant mode, there's one WeakMap per field, and in loose mode, there are no WeakMaps, since it's all based on string properties. It's important to track which instances have each individual field, since an initializer can throw an exception and leak an object that has some fields but not others. |
@littledan agreed, but I couldn't literally find related changes. If there's already a PR I'll have a look there, thanks |
New private props PR babel/babel#6120 |
Replaced with babel/babel#7555 |
Private fields shipped in https://github.com/babel/babel/releases/tag/v7.0.0-beta.48 TC39 is looking for feedback from the committee, since unlike public fields which has extensive usage/docs/videos/etc, private has not (even as Stage 3) since it hasn't shipped in Babel or other implementations until recently. |
The following seems to be allowed by the Babel parser: class Foo {
# p = 0;
constructor() {
this.# p ++;
}
print() {
console.log(this . # p);
}
} However, it seems to violate the lexical grammar in the spec proposal:
Is the intention that the transformation itself (not the parser) should disallow cc @ramin25 who helped find this, and @rricard, who is working on private fields. |
I can try to take a look when I'm done with static private fields (I'm getting there, slowly but I'm getting there, and @tim-mc helps me as well on this one). This issue though seems to be a parser-level issue, I never worked directly on that and only consumed the AST but that might be an interesting thing to try to fix. |
It should be disallowed by the parser 👍 |
Maybe some parts or ideas could be integrated? I think the specific code for ES5 could be removed and left only the private and protected parts, and left Babel to adapt it itself... By the way @trusktr, can you provide an example of protected attributes and methods? Examples seems to show only private ones... And are protecte attributes in any standard? |
@ljharb If lowclass (or similar idea) gets adopted into Babel, then it won't be "additional". :D
@piranna Sure, there's many examples in the tests. For example, search for "protected" in this file. Small example: // Parent.js
import Class from 'lowclass'
export default Class('Parent', {
protected: {
parentLog() {
console.log( 'Parent!' )
}
}
}) // Child.js
import Parent from './Parent'
export default Parent.subclass('Child', ({Protected}) => ({
childLog() {
Protected(this).parentLog()
console.log( 'Child!' )
},
})) // app.js
import Child from './Child'
const o = new Child
o.childLog() // it works
// output:
// Parent!
// Child!
o.parentLog() // ERROR, undefined is not a function (because it is not public) |
|
@trusktr I think the current style of output from Babel is good. I don't think "readable" output is a sustainable goal for Babel transforms for TC39 proposals, given that the language semantics are pretty subtle. If you want to propose particular semantics, I think that's better done in TC39 than in this repository; see CONTRIBUTING.md. |
I also don’t think it would be appropriate for Babel to contain any concept of “protected”, because the language has none - and it in my opinion is not likely to ever have one. |
@littledan Readability would only be a bonus. I'm just showing a runtime implementation that has all the features needed for everything in this proposal (and it can be tweaked). Maybe it'll can give someone ideas.
Not sure what you mean. JS has a We can easily add it. When I write classes, a large amount of the time I want "protected" (and I use I made a poll to see if people want protected (I hope some people will vote!): https://twitter.com/trusktr/status/1025466478626136064 |
By the way, it's possible to add encapsulation with This shows that such an implementation can exist on top of Babel's import protect from 'lowclass' // call it "protect" instead of "Class"
const Thing = protect( ({ Private }) => {
return class Thing {
constructor() {
// make the property truly private
Private(this).privateProperty = "yoohoo"
}
someMethod() {
console.log('Private value is:', Private(this).privateProperty)
}
}
})
const t = new Thing
t.someMethod() // "Private value is: yoohoo" The class definer function can return any class, for example one created with Babel helpers. Something like a |
@trusktr yes, and the private fields proposal intentionally and explicitly chose not to address "protected", and https://github.com/tc39/proposal-private-fields/blob/e704f531c33795ca34ede86e1c78e87798e00064/DECORATORS.md#protected-style-state-through-decorators-on-private-state shows how you can achieve protected without special syntax for it. |
I found a couple issues with the current implementation: babel/babel#8421. |
Interestingly, the problems described there are the same as in other languages. That version of "protected" is exactly the same as implementing "private" with a weakmap, then assigning the WeakMap onto each instance. Not very protected. There's valid cases for "protected" where protected members can not be public: An instance factory can provide instances, while the class hierarchy is encapsulated. Therefore, all the "protected" members are still hidden by design, and library maintainers can benefit from the protected pattern. Simply making everything public (like in the decorator example) isn't the same. |
Since JS has runtime subclassing, anything that's "protected" is in practice fully public. |
Oh yeah, I almost forgot about access to the prototype. A way to defend against that would be to have a library's leaf-most classes define a private property, leak the access helper inside the module scope (f.e. with |
I can't conceive of any way to do that that allows for subclassing at any time, even later, without risking exposing protected things to the world. I believe that it's truly impossible in JS to do this, which is why I think that "protected" is a wholly inappropriate idiom for the language. |
That's what I meant, you don't allow further subclassing. We could also introduce a
@bmeck shared with both of us the "gateway" pattern, which shows it is possible to (for example) throw an error for invalid imports. A simple implementation would be to track a counter inside a module scope which desires to have a "private" export, and increment the counter for every import of the private export. As a library author, we will know how many times the counter should be incremented. Once the counter goes beyond that number, we throw an error and leave the lib in a broken useless state. The person trying to use the library has no choice but to fork the library source code and change the code in order to import and extend the desired class. This is the same with any other language: if you have the source, you can do whatever you want to it. With this technique, we can export only a "final" class from a lib. This of course has implication on the library structure and implementation and how the user imports the export; that's the inconvenient part. But it's possible. We can abstract away some of the complexities involved with the gateway pattern for a specific use case. After thinking about this for a while, I think protected is still valid, and it is not the same as the fake still-public technique that the class fields proposal suggests using ( |
After using the gateway pattern, implementing the "final" class is easy, in a way that works in most cases: class FinalClass extends PrivateClass {
constructor() {
if (!this.__proto__ === FinalClass.prototype) selfDestruct()
}
} Well, anyways, if the language doesn't gain |
Better way: just check that `new.target === FinalClass`. That's precisely
what it's there for, and it's completely impossible to forge. It also
prevents weirdness like `Reflect.construct(FinalClass, [], String)` and
`Reflect.construct(FinalClass, [], ClassWithFinalClassPrototype)`.
…On Tue, Aug 7, 2018, 17:01 Joe Pea ***@***.***> wrote:
After using the gateway pattern, implementing the "final" class is easy,
in a way that works in most cases:
class FinalClass extends PrivateClass {
constructor() {
if (!this.__proto__ === FinalClass.prototype) selfDestruct()
}
}
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#12 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AERrBBb8hDxvC0Br4wZM1FIYK6PBg0vWks5uOgAjgaJpZM4OTUJC>
.
|
Please, I'd encourage you to have discussions about proposal semantics within TC39, rather than in the Babel project. |
Sweeet. So very possible to make use of a real
👍 |
@trusktr That's for "final class" within constructors, not "protected" methods. 😉 |
@isiahmeadows Yes, and if a library exports a "final" class, then this prevents end users from exposing protected members through class extension (they can't extend the final class). |
So therefore, |
@trusktr It doesn't protect methods, just the constructor. The best you can do is |
But either way, this is getting off-topic, so if that doesn't address your concerns, feel free to raise it on es-discuss. |
The protected members in my lowclass implementation are not exposed on EDIT: Oh, I see what you mean, that the prototype can still be extended without the original constructor. In this case, at least with My implementation can still make it work: the original constructor can keep track of instances in a module-scoped WeakMap, and the user's custom constructor can't. Then calling any methods can throw as useful message like "you can't extend this class. :P". TLDR It's doable, I can see the path to making it work. I might just add this to lowclass... A language Alright, will continue in ESDiscuss. |
Original issue submitted by @babel-bot in babel/babel#4408
Champions: @jeffmo (public class fields) @littledan (private + combined)
Spec Repo: https://github.com/tc39/proposal-class-fields
Spec Text: https://tc39.github.io/proposal-class-fields/
Slides: https://drive.google.com/file/d/0B-TAClBGyqSxWHpyYmg2UnRHc28/view
Examples
Parsing/ESTree
classProperties
andclassPrivateProperties
.Transform
Contacts
The text was updated successfully, but these errors were encountered: