Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...
claus.reinke at talk21.com
Thu Nov 3 03:07:41 PDT 2011
>> I'm not just talking about implementors, either. Some users
>> will want to know d.m isn't going to change. They may not
>> want to know that it's b.m, mind you -- they simply won't
>> want that c.m assignment to be legal, or else if they do
>> support such a thing, they don't want it to affect d's "vtable".
> I would argue that developers who rely on these kinds of
> assurances are actually slowing down their own, and others,
> productivity. Assuming they wrote the perfect method and it
> should never be changed is a grand claim for anyone who
> isn't Donald Knuth. Assuming that the consumer of their
> code is responsible for their own bugs if they introduce
> them with monkey patching class methods seems fair.
Ok, I have to wade in here: if you cannot see why some people
want such features, why are you arguing against these features?
[the "you" here is not (exclusively) about you, but about a pattern
often exhibited by vocal and repeated opposition to things:-)]
and this doesn't seem to be your discussion to have, does it?
You could try to argue that warnings are better to have than
interfering with your code's base assumptions, but you don't
want that to stop you from running that code anyway, knowing
that doing so might be unsafe.
Example: the switch from warnings to errors for non-essential
features of JSLint meant that many JS coders can no longer
use JSLint, so the switch actually reduced its effectiveness.
So, if a proposed feature interferes with your use of the language,
state that interference, and perhaps the proposals can be changed
to accommodate your concerns. That is a discussion based on
technical issues, which can make progress and can achieve targets.
However, you might consider how your personal perspective
affects your judgement:
- if you're developing node, you're at the start of the chain,
no-one can interfere with your definitions
- if you're developing node libraries, you have to keep up
with node only, but you have to do that anyway
- if you're using libraries from a single source only, you're
still not likely to be affected, because those libraries are
either consistent or have a bug that needs fixing
- if you're using libraries from several sources, you're
suddenly open to a lot of trouble, as any library from
source A might interfere with base assumptions made
by any library from source B
- if you're browsing the web, where many pages include
code from dozens of sources, you're out of luck quickly
if you cannot see what is conflicting with what
- if you're in the business of trying to ensure that web
users won't run into trouble, you want to pin down
what each page widget and ad module is allowed to
do (whitelisting); and if you take that to its conclusion,
you need to base your whitelisting in the language
I could go on about how types can be a tool, not an obstacle,
if zealotry can be avoided, or about how many (most?) people
who are well-known for doing reflective language features
(the stuff "dynamic" fans like most about JS) have expressed
the opinion (later in life, based on experience with their
systems) that reflective and normal use should be separated
as clearly as possible.
But I really just wanted to say: don't argue against features
you do not need, argue for features (or changes of features)
you do need.
If a feature you do not need interferes with something you
do need, that is a bug in the feature that should be pinned
down and addressed (dismissing the whole feature won't
help, unless the problem is unavoidably tied to the feature).
If a feature you do not care about takes resources you would
like to see spent on something you do care about, that may
be a bug in the process that
Just another opinion from another JS coder.
Btw, some message to es-discuss are still missing, and
es-discuss-owner has not replied.
More information about the es-discuss