Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

Brendan Eich brendan at mozilla.com
Thu Nov 3 16:11:01 PDT 2011


On Nov 3, 2011, at 1:56 PM, Harutyun Amirjanyan wrote:

>> "freedom" includes my ability to fence my yard.
> yep, but that fence can't be removed ever after.
> and if there are irremovable fences, it's important to make sure, they
> do not rise by themselves.

That's completely false. If my "fence" is a frozen object, I can remove the Object.freeze call later. My source can be forked to remove it sooner.

To follow the analogy, what you are insisting on is the right to take down my fence while I'm still living on my property.


> e.g. requiring "public" (thanks for not doing that:)

A different kind of public is in the latest gist, but it may not make it. It's simply to enable @foo instead of this.foo. It is not strictly necessary, per @mythz.


> freezing module scope.

Modules are not objects primarily, although they reflect as sealed objects. This gives early errors on typo'ed or otherwise mismatched exports/import mismatches.


> adding better syntax for @private variables (private variables in
> closures already have advantage by not needing "this.")
> are all luring people to build fences they don't need.

Closure pattern is fine for private variables until it scales to the point that the closure per method per object cost is too high. Then what?

BTW, a closure *is* a fence that you can never take down without a code rewrite (not just removing an Object.freeze call).


> to keep game fair,
> not building a fence should be at least as easy as building one.

That was never in dispute, since JS is so dynamic.

I think the idea that my ability to build *and maintain* fences -- or even walls in my house -- limits others' freedom is a fraud. It's anti-freedom.

/be



More information about the es-discuss mailing list