1. 4

  2. 4

    I’ve through the blog post, the associated proposal, some of the draft specs, and a bunch of other stuff.

    Nowhere do I see anything that motivates this. Why is this feature being added? What problem does it solve? Why is the leading underscore convention insufficient? The draft specs suggests that there is significant new complexity added to various core algorithms in the object system, but it feels unjustified.

    Is it just assumed that “encapsulation” is good and therefore necessary? Is it further assumed that enforced encapsulation is a requirement? Is there speculation that JavaScript may be eventually object-capability secure? Is that even a feasible goal? Would it even be useful in the absence of process abstractions? Feels like more skyscrapers on foundations for sandcastles.

    1. 3

      Apparently you overlooked the proposal’s FAQ answer “Why is encapsulation a goal of this proposal?”, which is linked from the middle of the article. This is the proposal’s reasoning:

      Library authors have found that their users will start to depend on any exposed part of their interface, even undocumented parts. They do not generally consider themselves free to break their user’s pages and applications just because those users were depending upon some part of the library’s interface which the library author did not intend them to depend upon. As a consequence, they would like to have hard private state to be able to hide implementation details in a more complete way.

      1. 1

        I agree with this overall sentiment. It seems un-necessary.

        Perhaps there is a performance angle to this somehow? Since external code can’t reference these fields, yada yada yada

        I feel like Javascript has hit a pretty good spot in terms of utility with recent revisions, at least for front-end work. I understand more people want to get this stuff into the backend as well, but do we really need runtime support for this? Typescript could surely offer you similar functionality on a static level.

        I want to know the reasons

        1. 1

          Unlike the leading underscore convention, it prevents access to private state from outside the object. In some ways it is a formalization of the leading underscore convention. A leading underscore is just a hint that can be abused intentionally or accidentally, without any error being indicated.

        2. 2

          The proposed # syntax is surprising to me, considering that private is reserved since forever.

          I’m probably being dense, but I don’t understand the rationale presented in the post. Expensive runtime checks are already pervasive (with JIT refunds,) as is unexpected behavior when you get your types wrong. What am I missing?

          Edit: care should of course be taken not to introduce more inefficiency and footguns, but consistency is valuable, too. It’s also unclear to me how other access modifiers, like protected, would be supported by future revisions of the language.