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

41–50 of 81 posts

Re: JavaScript TC39 implementing hashmark private class fields

#41

Post by simplify »

frou_dh wrote: post #40
simplify wrote: post #31

Why are private properties so sorely needed? Ruby is an OOP language, and gets along just fine without it.

Admittedly I have barely used Ruby, but isn't the fact that those "attr_reader"s have to be declared explicitly an indication that the fields are private by default?

attr_reader :my_prop is just a shorthand way of creating a convenience method that returns the internal value of @my_prop. But in any case, there is always a way to access a Ruby object's internal instance values. See my other comment in this thread.

Re: JavaScript TC39 implementing hashmark private class fields

#42

Post by jkrems »

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…

Downvoting this comment because:

1. Afaik every single OO language allows this. I wouldn't know of prior art for the opposite behavior (only allowing access to the same object).

2. TypeScript works under different constraints and - for all intends and purposes - doesn't implement private properties when it comes to the final, running program. The reasons why TypeScript isn't a battle test solution are laid out pretty explicitly in the Github thread.

Re: JavaScript TC39 implementing hashmark private class fields

#43

Post by pmalynin »

aturek wrote: post #20
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…

In answer to (1) - I'm a bit rusty, but I believe Java allows objects of the same type to access other objects' private data. I definitely agree that it's gross, but it exists elsewhere.

Also C#

Re: JavaScript TC39 implementing hashmark private class fields

#44

Post by dmitriid »

just_astounded wrote: post #14
watty wrote: post #7

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

I think the concern is that if you look here: https://github.com/tc39/proposal-private-fields/issues/14 and other places, you'll see this massive push back from the community, yet the proposal is moving forward regardless.

Pushback from the community means nothing to TC39. Zilch. Zero. Nada.

The only instance of something dropped was cancelable observables. AFAIR it was only because some other group at Google opposed it.

Everything else is carried full steam ahead. Enjoy your import() instead of the vastly superior System.loader. Enjoy your hashes as member access specifiers. Dumpster fire. Template literals. BigInts. `new.target`. Dumpster fire. `import.meta`. Dumpster fire

Re: JavaScript TC39 implementing hashmark private class fields

#45

Post by RyanCavanaugh »

jkrems wrote: post #42
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…

Downvoting this comment because: 1. Afaik every single OO language allows this. I wouldn't know of prior art for the opposite behavior (only allowing access to the same object). 2. TypeScript works under different constraints and - for all intends and purposes - doesn't implement private properties when it comes to the final, running program. The reasons why TypeScript isn't a battle test solution are laid out pretty…

The only mainstream language I'm aware of (having looked into this before because someone complained about it re: TypeScript) that disallows cross-instance private access is Ruby.

Re: JavaScript TC39 implementing hashmark private class fields

#46

Post by Andrex »

jorblumesea wrote: post #23

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 bu…

You don't need all aspects of OOP ever to get use out of some of its concepts. ES2015 classes are much cleaner and easier for newbies to grok than messing with the prototype chain, which was the way that sort of thing was achieved before.

Classes also make a lot of sense for custom elements (Web Components.) See Polymer v1 compared to v2.

Re: JavaScript TC39 implementing hashmark private class fields

#47

Post by jorblumesea »

Andrex wrote: post #46
jorblumesea wrote: post #23

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 bu…

You don't need all aspects of OOP ever to get use out of some of its concepts. ES2015 classes are much cleaner and easier for newbies to grok than messing with the prototype chain, which was the way that sort of thing was achieved before. Classes also make a lot of sense for custom elements (Web Components.) See Polymer v1 compared to v2.

Es2015 classes are just syntactic sugar around prototypically inherited objects. I agree they are nicer to use but under the hood there's no change. Which is why adding all of these oop concepts seems contrary to how the language is designed. At the end of the day JS has no true classical classes.

Not an expert just my opinion.

Re: JavaScript TC39 implementing hashmark private class fields

#48

Post by bcherny »

jkrems wrote: post #42
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…

Downvoting this comment because: 1. Afaik every single OO language allows this. I wouldn't know of prior art for the opposite behavior (only allowing access to the same object). 2. TypeScript works under different constraints and - for all intends and purposes - doesn't implement private properties when it comes to the final, running program. The reasons why TypeScript isn't a battle test solution are laid out pretty…

> Afaik every single OO language allows this.

Ruby and Scala disallow it, to name two (edit: to clarify, Scala supports both modes via private and private[this]). I stand corrected on Java, C#, and C++.

> The reasons why TypeScript isn't a battle test solution are laid out pretty explicitly in the Github thread.

I didn't see that, can you point me to it? Yes, in TS it's a compile-time-only check (as are all TS checks), but what does that have to do with reusing the same keyword for a runtime check?

Re: JavaScript TC39 implementing hashmark private class fields

#49

Post by munificent »

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?

Almost every statically typed OOP language works this way. In C++, Java, and C#, privacy is class-based, not instance-based.

Privacy is instance-based in Smalltalk and, as I understand it, has been a long-time source of frustration. It makes it very difficult to implement things like an equality method so that an object can compare itself to another of its own type without breaking its own encapsulation.

If you think about it from the perspective of software engineering (and not security, which is generally not what language-level privacy is for), instance-based privacy has no benefits over class-based privacy.

The goal of access control is to encapsulate regions of code from each other so that modification to one doesn't affect others. It establishes fences between different parts of the program to make them less coupled to each other and easier to independently change.

Every instance of the same class shares the exact same code, so there is no point in preventing access between them. It's not like you can encapsulate things such that a change to class A doesn't require a change to... class A. That's the same class that you're already touching.

> We should be looking to TypeScript's private/protected modifiers as a battle tested solution that fits the existing convention set by the "static" modifier.

I believe those rely on static analysis, which JavaScript does not have.

Re: JavaScript TC39 implementing hashmark private class fields

#50

Post by Andrex »

jorblumesea wrote: post #47
Andrex wrote: post #46

Earlier quoted context omitted.

You don't need all aspects of OOP ever to get use out of some of its concepts. ES2015 classes are much cleaner and easier for newbies to grok than messing with the prototype chain, which was the way that sort of thing was achieved before. Classes also make a lot of sense for custom elements (Web Components.) See Polymer v1 compared to v2.

Es2015 classes are just syntactic sugar around prototypically inherited objects. I agree they are nicer to use but under the hood there's no change. Which is why adding all of these oop concepts seems contrary to how the language is designed. At the end of the day JS has no true classical classes. Not an expert just my opinion.

Good point! I do think that private properties is a worthwhile endeavor though, even if it's more of a "hard OOP" concept that on the surface conflicts with the historical ES spec.
Post reply on HN