Matt said:
The fact that the decision is rather arbitrary is a good
reason to not treat it as a rule.
Of course it is arbitrary. Any character could have been used, although
attaching such significance to an alphabetical character obviously would
not have been a good idea.
Is there any logic behind saying that identifiers beginning
with $ should only be from generated code?
Is there any logic behind allowing '$' to be a leading character in an
Identifier at all? Why not '@', '# 'or '~'? It strikes me that '$' may
be in the set of characters allowed specifically in order to make it
available for that one specific use.
Conventions such as class names / namespaces beginning with
a capital letter are common because they occur so often.
Machine-generated javascript is not all that common,
The relative uncomments of machine generated Identifiers does not mean
that it is not useful to be able to indicate their status in a clear and
well known way.
and certainly not to anyone at the
level of using tools like prototype.
And it makes perfect space to let people who don't really know what they
are doing impose on ongoing maintenance expense on any code they are
involved with?
Any other naming suggestion? ...
Something that states what the function actually does?
Not at all. Specifications are not often meant to be read
by humans, but rather as a reference for people writing
implementations of the specs.
There are certainly some things to be learned from the ECMA
Spec, but it seems that the primary reason for being familiar
with it is to be able to tell others how stupid they are here
in this group.
You are a fool if you think that. ECMA 262 is the only source that
provides some very useful information. Where else are you going to find,
for example, a statement of which side of a comparison expression is
evaluated first, or a better statement of what it is that represents the
language core that can be expected to work in all implementations (so
stripped of the implementation specific extensions)?
I'm much less impressed by someone who is very familiar
with the specs than with someone who can do something
practical and useful with the working knowledge they have.
Javascript has always offered plenty of potential for doing things that
are "practical and useful" extremely badly. I cannot think of a single
individual whose javascript code I would want to go out of my way to
read who does not have some familiarity with the contents of ECMA 262.
Reading ECMA 262 may not be a panacea for good javascript authoring of
itself but (and certainly in the absence of a better source of the same
information) a familiarity with its content does promote a better
understanding of how javascript works. Which has very practical
consequnces.
People who fit into both
categories are rare!
People who know javascript well are rare.
How many C, C++, Java, etc developers do you
know who have read the language specs cover to
cover?
C, C++ and Java developers have good alternative sources for the level
of detail they need, Javascript does not. There are entire
implementations where the documentation consists of no more than stating
that they are ECMAScript implementations. Without knowing what
ECMAScript is how are you going to know what could be expected to work
in NetFront 4, for example?
Even very skilled and experienced developers do not read the
specs for the languages and tools that they use unless they
get really deep into it.
How many skilled developers have fallen into the trap of thinking that
javascript is block scoped like Java, or made assumptions about the
value of - this - and then been disappointed that javascript did not
work that way?
More people are familiar with prototype's use of $() than
the specs convention for $ in identifiers. (Based on
unscientific observations of this group, support emails I
receive, and people I've worked with)
<snip>
If both groups are not that large then a personal sample is not going to
be representative.
There is no reason to allow the propagation of a mistake among people
who don't know any better get in the way of a well known, documented
convention that serves a more useful purpose, even if it is not needed
to do so very offten.
Richard.