Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript TC39 implementing hashmark private class fields

github.com

Post reply on HN
Print view View original

21–30 of 81 posts

Re: JavaScript TC39 implementing hashmark private class fields

#21

Post by JoshTriplett »

bcherny wrote: post #18
watty wrote: post #7

Seems like a pretty fair and well though out solution after reading the latest response by bakkot.

I read through the thread, and the proposal sounds crazy to me. 1. Members marked private being accessible from other instances of the same class [1] is counter to every other OO language I have used. What is the prior art here? Why depart from all conventions like this? 2. The # syntax is not extensible. If TC39 decides to add protected, internal, etc. modifiers in the future, what will they look like? We should be…

> 1. Members marked private being accessible from other instances of the same class [1] is counter to every other OO language I have used. What is the prior art here? Why depart from all conventions like this?

C++ works that way, and several other languages do as well. And the use case mentioned in that comment is exactly the reason: the implementation of a class knows how to access both its own private fields and those of another instance of itself, so that it can do comparisons, combinations, or other operations.

Re: JavaScript TC39 implementing hashmark private class fields

#22

Post by pavlov »

A noteworthy feature of JavaScript is that it is predominantly a scripting language for large OOP-designed C++ systems. All the major browsers are C++ underneath, and so is Node.

This has created an odd tension where the APIs that programmers use are implemented as OOP under the hood, yet JavaScript itself shied away from OOP concepts. With features like this, the JS standard is slowly creeping towards the style of programming that underlies the ecosystem.

Re: JavaScript TC39 implementing hashmark private class fields

#23

Post by jorblumesea »

True "Classes" in JS always seemed like a hack anyways. It will never be true OOP, so why shoehorn these concepts into it? Especially given prototypical inheritance patterns we will never have real java style oop patterns. Except for primitives, almost everything is an object, but they are basically hashmaps, not real classes or objects as someone from other languages might think of them.

Imo, the language was not build or designed for some of these heavier OOP concepts. Just my opinion.

This seems to fly in the face of many of the great things ES6 implemented.

Re: JavaScript TC39 implementing hashmark private class fields

#24

Post by stupidcar »

just_astounded wrote: post #13
rocky1138 wrote: post #11

This is the primary reason I didn't like the idea of adding "classes" to JavaScript in the first place. Classical OOP doesn't really have a place here and all it does is invite the wrong type of thinking into the language.

Agreed. We already had solutions for inheritance, etc... using prototypes, which are more powerful than classic OOP. Now we're in sort of a mess hybrid thing where issues like this are mostly unsolvable in a clean way.

JS classes build on prototypal inheritance, they aren't an alternative mechanism. So you apparently either don't understand them, don't understand "classic OOP", or both.

Re: JavaScript TC39 implementing hashmark private class fields

#25

Post by BinaryIdiot »

jwalton wrote: post #5
blargathon wrote: post #2

Kinda disappointing. I don't really like the # for privates. It's not an elegant solution. It feels a bit like a one-off hack honestly.

Right now I'm prefixing variables I don't want external actors to change with underscores, which doesn't actually do anything, so is arguably more of a hack. :P

You could encapsulate them with a closure. They don't _need_ to be exposed.

Re: JavaScript TC39 implementing hashmark private class fields

#26

Post by pitaj »

bcherny wrote: post #18
watty wrote: post #7

Seems like a pretty fair and well though out solution after reading the latest response by bakkot.

I read through the thread, and the proposal sounds crazy to me. 1. Members marked private being accessible from other instances of the same class [1] is counter to every other OO language I have used. What is the prior art here? Why depart from all conventions like this? 2. The # syntax is not extensible. If TC39 decides to add protected, internal, etc. modifiers in the future, what will they look like? We should be…

The answer to #2 is that you can just put a private / protected keyword in front of the `#prop` declaration. The difference between public and protected, etc is larger than the difference between private and protected, etc.

Re: JavaScript TC39 implementing hashmark private class fields

#27

Post by spankalee »

JoshTriplett wrote: post #21
bcherny wrote: post #18

Earlier quoted context omitted.

I read through the thread, and the proposal sounds crazy to me. 1. Members marked private being accessible from other instances of the same class [1] is counter to every other OO language I have used. What is the prior art here? Why depart from all conventions like this? 2. The # syntax is not extensible. If TC39 decides to add protected, internal, etc. modifiers in the future, what will they look like? We should be…

> 1. Members marked private being accessible from other instances of the same class [1] is counter to every other OO language I have used. What is the prior art here? Why depart from all conventions like this? C++ works that way, and several other languages do as well. And the use case mentioned in that comment is exactly the reason: the implementation of a class knows how to access both its own private fields and th…

It gets really tricky when you have any kind of polymorphism, intended or not.

If you accept instances of your own class as arguments to a method, you may be templated to think you can access the private fields of those arguments, even if instanceof checks pass, but they may not be there.

Re: JavaScript TC39 implementing hashmark private class fields

#28

Post by agentultra »

The keywords were reserved in the latest spec for just this purpose.

I don't think the rationale for their inclusion is a good one. The inclusion of such keywords in languages like C++, Java, etc was well-meaning but a mistake in retrospect. In the presence of global variables and direct assignment these keywords are the PHB approach to information hiding. They require ceremony and diligence to achieve true encapsulation. It's a murky situation at best.

See Bob Martin https://www.youtube.com/watch?v=TMuno5RZNeE&t=2325 and Bertrand Meyer on Eiffel: http://se.inf.ethz.ch/old/teaching/ss2007/0050/slides/03_sof... (Bertrand Meyer coined the Open/Closed Principle and is the developer behind Eiffel).

At this point though I see their inclusion in JS being almost inevitable. Just another feature to ignore.

It'd be nicer if they would look to add syntax for higher-order operators like compose to the language instead of this.

Re: JavaScript TC39 implementing hashmark private class fields

#29

Post by pitaj »

just_astounded wrote: post #16
pitaj wrote: post #4

Earlier quoted context omitted.

There's not really a better way while maintaining encapsulation.

Don't we already have solutions (closures/WeakMap) for hard encapsulation? Seems like '#' just pollutes the language and isn't really needed.

There are solutions, but people want a syntax solution for it. Personally, I think that private instance properties should be a separate proposal from static and instance properties. That way, people could decide if they want some of it, or all of it.

Re: JavaScript TC39 implementing hashmark private class fields

#30

Post by cromwellian »

BinaryIdiot wrote: post #25
jwalton wrote: post #5

Earlier quoted context omitted.

Right now I'm prefixing variables I don't want external actors to change with underscores, which doesn't actually do anything, so is arguably more of a hack. :P

You could encapsulate them with a closure. They don't _need_ to be exposed.

Does this scale in a large code base? What's the effect on memory and performance of hiding most of your fields by closures?
Post reply on HN