I don't understand why you would do this.
If you want to break a program, you can break it one way or another, so why try to chase the perfect level of encapsulation? Most languages who support encapsulation better than JS, still allow access through reflection. It's an endless cat and mouse game. To what end?
In the end, it's important that your code communicates how it should be used,
that the right way is most convenient and well surfaced, and the wrong way is harder. private works just fine to achieve exactly that and other modifiers like readonly etc.
The only imo minor inconvenience of private compared to # is collision. Python solves that by prefixing the variable name with _ClassName_, transparently for you. You can do the same manually. Again it communicates that this variable should be considered as private state to the said class.
Sure # just makes it more convenient, so that's nice, but definitely not a requirement to me.
Nice hack to use WeakMap, but to me it's a waste of effort, increased maintenance hurdle/cost, cognitive load, and maybe even performance. Each much more important than achieving the perfect level of encapsulation imo.
Patrick Roza, thank your for the replay, in my example I'm talking in the context of the current JS implementation not the next JS or TS, for sure typescript solved the issue for now with private properties/methods.
I use encapsulation mainly to avoid shared mutating state issue and avoid an example like the following:
deleteobj.someProp;
I can freeze or use Object.defineProperty to achieve it, the later is more waste of effort.
I don't think that using WeakMaps has a big performance impact compared to closures.
I see, in TS trying to delete obj.someProp where someProp is marked readonly will be prevented by compiler.
yea I just noticed that in vanilla JS you are kind of left to the harder options like closures or Weakmap.
At the same time, JSDoc may be helpful too, as said communication is the most important part imo, achievable by:
naming: e.g _myprivate, _MyClass_myprivate etc
documentation: e.g /** @private */
tooling support for said options (lint/doc/editor)
Editor support is of course very helpful, and in that, I think TypeScript as a supported standard is perhaps very helpful.
I don't understand why you would do this.
If you want to break a program, you can break it one way or another, so why try to chase the perfect level of encapsulation? Most languages who support encapsulation better than JS, still allow access through reflection. It's an endless cat and mouse game. To what end?
In the end, it's important that your code communicates how it should be used,
that the right way is most convenient and well surfaced, and the wrong way is harder.
privateworks just fine to achieve exactly that and other modifiers likereadonlyetc.The only imo minor inconvenience of
privatecompared to#is collision. Python solves that by prefixing the variable name with_ClassName_, transparently for you. You can do the same manually. Again it communicates that this variable should be considered as private state to the said class.Sure
#just makes it more convenient, so that's nice, but definitely not a requirement to me.Nice hack to use WeakMap, but to me it's a waste of effort, increased maintenance hurdle/cost, cognitive load, and maybe even performance. Each much more important than achieving the perfect level of encapsulation imo.
Patrick Roza, thank your for the replay, in my example I'm talking in the context of the current JS implementation not the next JS or TS, for sure typescript solved the issue for now with private properties/methods.
I use encapsulation mainly to avoid shared mutating state issue and avoid an example like the following:
I can
freezeor useObject.definePropertyto achieve it, the later is more waste of effort.I don't think that using
WeakMaps has a big performance impact compared to closures.I see, in TS trying to
delete obj.somePropwheresomePropis markedreadonlywill be prevented by compiler.yea I just noticed that in vanilla JS you are kind of left to the harder options like closures or Weakmap.
At the same time, JSDoc may be helpful too, as said communication is the most important part imo, achievable by:
_myprivate,_MyClass_myprivateetc/** @private */Editor support is of course very helpful, and in that, I think TypeScript as a supported standard is perhaps very helpful.
I agree, I use the example above for domain modeling with JS on nodejs, not in every part of my applications.
As you said, communication is important so I started switching to typescript.
+1 for the JSDoc.