Prototype properties :(

[bathos]

If I understand correctly, this proposal has succeeded the Orthogonal Classes proposal. Unlike that iteration, which allowed non-method, non-accessor properties of all three targets to be defined within a class body, this seems to omit prototype properties — i.e. post-declaration Object.defineProperty(Foo.prototype, ...) will still be required.

I found the reasoning behind this change at https://github.com/littledan/proposal-unified-class-features/blob/master/DETAILS.md#type-implies-placement

Not that it counts for much but ... I wish it weren’t so. I have used non-method value properties on prototypes often enough to think this is a weird hole; they're useful in particular for inheritance cases where only a subset of instances needs a dynamic value or a subset of extended classes have a different value.

[littledan]

This proposal leaves the door open for prototype properties, actually. The logic explained in @jeffmo's presentation is that it's more about "default placement"--methods have default shared placement, and fields have default instance placement, but potentially, the opposite of both could be achieved with (optional) own and shared keywords. I'll update the proposal-unified-class-features document to explain this logic.

[bathos]

Ah, that’d be a pretty sweet best-of-both-worlds solution. I’ll close this since it’s not really an issue proper & it is reassuring to see that this wouldn't shut the door on "full package" syntax for class bodies.