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

Claus Reinke 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:-)]

The Javascript user base is huge, with obviously different views,
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
errors in Javascript, eg, it should be easy to spot if someone is
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.

Claus
http://clausreinke.github.com/
http://clausreinke.github.com/js-tools/
 


More information about the es-discuss mailing list