package

[Garrett Smith]

Garrett Smith wrote:
David Mark wrote:
Carl Forsman wrote:
On Mon, 17 May 2010 23:57:41 -0400, David Mark

Carl Forsman wrote:
On Mon, 17 May 2010 23:41:38 -0400, David Mark

Carl Forsman wrote:
[...] [...]

<del>
Sort of. Identifiers aren't supposed to use the $ character unless
they
are machine-generated. In most cases, _invalid_ syntax results in a
parse error (but not always).
</del>

<ins>
The dollar sign ($) and the underscore (_) are permitted anywhere in an
IdentifierName.
</ins>
What are you talking about? You know what the specs say about $. How
many times have we discussed this? And who said anything about
underscore?

Also, why did you <del> the bit about invalid syntax?

Uh-oh. I over <del>'d didn't I?

But yes, I know what the specs say about `$`. Is ECMAScript Edition 5
not quoted verbatim within <ins>?

Why do you cite irrelevant documents (e.g. HTML5, DOM3, etc.) These
things aren't in widespread use yet, so who cares what they say at this
point?

Did I cite HTML5 and DOM3? Nope, I sure didn't.


Whether or not DOM3 is in widespread use is totally and utterly irrelevant.

ES 5 is done and it would not be incorrect to say that the pertinent
part of the spec that we are discussing is properly implemented in all
major implementations.

 

[David Mark]

David Mark wrote:
Garrett Smith wrote:
David Mark wrote:
Carl Forsman wrote:
On Mon, 17 May 2010 23:57:41 -0400, David Mark

Carl Forsman wrote:
On Mon, 17 May 2010 23:41:38 -0400, David Mark

Carl Forsman wrote:
[...]
[...]

<del>
Sort of. Identifiers aren't supposed to use the $ character unless
they
are machine-generated. In most cases, _invalid_ syntax results in a
parse error (but not always).
</del>

<ins>
The dollar sign ($) and the underscore (_) are permitted anywhere
in an
IdentifierName.
</ins>
What are you talking about? You know what the specs say about $. How
many times have we discussed this? And who said anything about
underscore?

Also, why did you <del> the bit about invalid syntax?
Uh-oh. I over <del>'d didn't I?

But yes, I know what the specs say about `$`. Is ECMAScript Edition 5
not quoted verbatim within <ins>?

Why do you cite irrelevant documents (e.g. HTML5, DOM3, etc.) These
things aren't in widespread use yet, so who cares what they say at this
point?

Did I cite HTML5 and DOM3? Nope, I sure didn't.

You have a habit of doing so. DOM3 popped up in a missive to a beginner
just the other day.

Whether or not DOM3 is in widespread use is totally and utterly irrelevant.

See above.

ES 5 is done and it would not be incorrect to say that the pertinent
part of the spec that we are discussing is properly implemented in all
major implementations.

Why are you citing that spec, when there is a perfectly good one that is
in widespread use?

 

[Garrett Smith]

The question was whether starting an identifier with a dollar sign was
unwise.

Well, yeah. Thomas said that the dollar function itself was unwise. I
though that was kind of odd. I realize you wouldn't say something like
that. Sorry about that .

[...]

I actually agree with all of the above.
Of course, document.getElementById is self-documenting, but you get old
writing it 100 times in a row. It's such a basic operation in browser
scripting that most everybody has created a shortcut for it. I'd be
surprised if you didn't.

Why would I create an abstraction that adds no value? Typing
getElementById five times per 100 SLOC is not outweighed by the cost of
having to manage the getElementById abstraction. It's really not a big deal.

You see shortcuts like that in all the

programming languages (well, except maybe for Java); for example, the
function/macro to get translated text is often "_". Yes, just the
underscore. The point about using $ in function names is to signal
"attention: special" to the reader. It shouldn't be abused, but if
you've got a good reason to use it, why not.

What good reason?

I do not agree with this.

Special? What does that mean and why do you need a special method? My
answers are "who knows" and "I don't", but you seem to disagree with those.

So you go and look it up once, like you do with any other function
you're not familiar with. Mind, you don't _have_ to use it. You could
just as well write jQuery(...) all the time, or ele(...) or

Neither of those are meaningful.

Lib.select(...)

Does that call a select method of a Range? Perform an SQL action? Select
the text in a form control?

Or does it do something that might be better expressed as:

Lib.querySelectorAll( pattern, doc );

or whatever you want to use. Just create a name that

suits your needs. My needs are served well with $. (outside of the
library itself, that is)

No, not whatever.

Do not name your methods whatever. Name them by what they do completely.
If a method cannot be completely described in an identifier, then what
the method does ought to be reexamined to determine if it is doing more
than one thing and not adhering to good old SRP.

Yeah, good luck with that

As a reviewer, I don't need any luck, just the code guidelines document,
which provides useful advice:

| Give each identifier a meaningful name.

Would you like to comment or add to that advice in any way?

It's not a meaningful identifier. It's a shortcut.

But to what? Can what `$` does be described in an identifier?

The fundamental concept of Identifier wants terseness. It encourages
methods that do one thing, which has the consequence of making the code
self-documenting.

If anyone wants to pick apart my code and tell where I've not followed
my own advice, please, I want to find those cases. I want the API to be
as obvious as possible and need no documentation.

 

[Thomas 'PointedEars' Lahn]

I honestly can't think of any, except in regular expressions. There's no
potential for ambiguity in those.
RTFM.

The passage about "mechanically generated code" in the specs is vague
enough to be practically useless.
No.

In the end, all of my code which gets delivered to the UA has been
processed and automatically modified in some way (although maybe not
"mechanically" - because it was produced by a PHP script, or assembled
with a build script, or because it has been minified.

By the way, none of the available minifiers (that I know of) add dollar
signs when they replace identifiers. That would have been the intended
use case of the dollar-identifiers, but it hasn't caught on, and so the
suggestion was dropped in ES5.

That is a fallacy.

Okay. Maybe that wasn't such a clever idea.

Maybe you should have asked a better question.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Well, yeah. Thomas said that the dollar function itself was unwise.

No, I did not. But it is true nevertheless.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Why do you cite irrelevant documents (e.g. HTML5, DOM3, etc.) These
things aren't in widespread use yet,

W3C DOM Level 3 is, since quite a while. But he did quote _ES_5; typo of
yours?

You two want to learn to quote. There is no need to keep attribution lines
for things that are not quoted. Which also indicates that this is about to
turn into a subthread fewer people are interested in.


PointedEars

 

[Richard Cornford]

I honestly can't think of any, except in regular expressions.
There's no potential for ambiguity in those.


Indeed, I'm very concerned about code maintainability. In this
case, however, I don't really see the problem.

I admit I've been using a $() function myself, long before
jQuery and the new host of JS libraries entered the game.
I saw it in an early release of Prototype.js, and after
confirming that it was indeed syntactically fine, I decided
to borrow the idea.

As have so many others (and I don't think it originated with
Prototype.js, though that library may have popularised the idea). One
of the consequences of using an explicit, meaningful Identifier (in
writing self-documenting code) is that you only see naming collisions
if you have to functions (methods/object, at the same 'level') that do
the same thing (at which point one of them is redundant and can be
removed). The use of non-meaningful and short/'convenient' Identifiers
in non-restrictive scopes directly leads to a high risk of naming
collisions, hence JQuery's 'no conflict' stuff (and associated
additional hoops to be jumped through).

Trends suggest an increasing frequency of web contexts where code
originating from multiple independent sources is going to find itself
being imported into single documents, and so find its self sharing a
single global object. In that context it becomes absurd to be choosing
a short/'convenient' Identifier as your code's exposed public entry
point.

My version isn't much more than a glorified wrapper for
document.getElementById (no CSS selectors or other magic),
and it's not exported by default - you'd have to do something
like 'var $ = LibraryName.byId'. The only problem I can
see here is that (today) people would probably assume $ to
be an alias for jQuery.

That would probably depend on the depth of their experience. The more
experienced should know not to assume anything from a $ identifier. On
the other had, anyone seeing - .getElementById - with and appropriate
argument, and making the obvious assumption will not be wrong often
enough to worry about doing that.

I can live with that.

I also use $identifiers to mark global variables from external
sources. For example, an included script could require a value
that can only be provided by the current server-side language.
Then there'd be a <script> element with something like
'var $USER_HOME = "/home/thomas"' in the PHP or JSP file, and
these external constants will immediately stand out when you
read the script.

That is pretty much the standard example of using the $ symbol to mark
mechanically generated identifiers (it is more like mechanically
initialised variables, but is still a useful way of flagging the
origins of the value stored by the variable).

The passage about "mechanically generated code" in the specs is
vague enough to be practically useless.

That depends. It does state why the $ symbol was included in the set
of characters that are allowed in an Identifier when it could just as
easily have been omitted.

By the way, none of the available minifiers (that I know of)
add dollar signs when they replace identifiers.

Why would they? Adding characters is hardly going to contribute
towards minimisation.

That would have been the intended
use case of the dollar-identifiers,

Not "the intended use case", rather one possible use case, if it was
not directly at odds with what minifiers are supposed to do. Remember
that facilitating an abilty to indicate mechanically generated code
does not then make a requirement to use that facility with all
mechanically generated code.

The case you mentioned above is a much better example; where the $
symbol is telling you that if the value stored is at odds with what
you were expecting then it is the server-side code that needs looking
at rather than the client-side.

but it hasn't caught on, and so the
suggestion was dropped in ES5.

It was almost certainly not its use (or non-use, if we accept "hasn't
caught on") with machine generated code that provoked the change in
ES5. After all, how could the ECMA committee know the extent to which
the $ symbol is or is not used in mechanically generated code?

It is much more realist to suppose that the ECMA committee observed
that the $ symbol had been employed in numerous 'popular' libraries,
was then in widespread use for a huge variety of other reasons (and
suggested meanings), and so recognised that the ability to employ it
to signify mechanically generated code had been neutralised. Basically
a recognition that the horse had bolted, and given that there was no
longer any point in keeping a stable for it.

I can perfectly understand that some people don't like '$'s
in their identifiers. I'm usually as diplomatic as I can be, but
when the topic is code style preferences, I can be as fascistic
as any other full-time developer The way I see it, '$'s don't
cause problems, and they can be useful as a convention to denote
"special" cases, so I use them. Others don't.

<snip>

The problem with 'special cases' is that there are many, and they
start to risk overlapping as their number increase. Apparently JQuery
developers, for example, have been encouraging the use of a leading $
symbol to indicate a variable or property name that holds a reference
to a JQuery object (the object returned from calls to - $() -). That
doesn't seem such a bad convention in the context of JQuery code.
Another suggested convention was to use a leading $ symbol to indicate
variable that held string values (apparently inspired by the syntax of
some other programming language, and proposed by an individual who
couldn't see that some of the values he was assigning to these
variables were actually numbers, undermining the notion form the
outset). VK proposes a 'convention' where a leading $ symbol get used
in property names (but not in any sort of consistent way over time).
In any single context any one such convention can be usefully
employed, but try mixing them together and the outcome is that each
becomes useless on it own and acts to confuse developers more familiar
with any other.

The thing that worries me here is that we have an OP who should have
been seeing ordinarily function/method calls in the code he posted but
was instead seeing (apparently undocumented) syntax extensions for
defining "classes" and "packages". It is difficult to see the $
symbols used in that code as not contributing to the misperception.

Richard.

 

[Scott Sauyet]

On 19/05/10 13:32, Richard Cornford wrote:
I realize that this is not very Web2.0 of me, but I'd have to say: so
don't mix incompatible libraries, or incompatible concepts. They all
have their "special" cases. If I were to include several different
libraries on one page, how would I keep their "special" cases separate
from mine? I can't. I can't even keep their "special" cases separate
from each other. My solution is to keep possible conflicts to a minimum,
but not to worry too much about the rest.

This is good advice in general. But don't be too scared to make
exceptions. Many of the more popular libraries work hard to have very
little footprint in the global namespace. You're not likely to
confuse things if the code working with these libraries always starts
with "dojo" or "YAHOO" or "jQuery". I don't think that jQuery is the
only one that offers a means to reset the "$" alias to its previous
value.

The conceptual differences are harder. MooTools wants you to think of
everything as an object, and uses objects to contain most program
state. jQuery would rather you used chainable functions for
everything and keep state in closures. Trying to combine these ideas
is difficult. And of course some libraries (Prototype and MooTools
most notably) modify the prototypes of various built-in objects.
Trying to use more than one of these libraries on a project could be
frightening.

 

[David Mark]

Typing should not be a consideration. Use macros.

It's a matter of convenience. Once you know it, a visual pattern like
$("elementId") is very easy to recognize, and it reduces the number of
characters you have to read and write.

I don't really follow that.

But as I said, it's an optional
extension. I like it; if you don't, then don't create or use the alias.

If you have a need to add something to it (e.g. a fallback for
document.all, normalization of IE's bugs), then it makes perfect sense.
For instance, the almost universally known abbreviation is gEBI.
Nothing wrong with that. I expanded that to getEBI in My Library.

Well yeah, I do. Of course I can live without the "special" methods, but
they make my life easier.
To answer your questions:

* what does that mean?

Indeed, "who knows". It depends on the library you're using. In my case,
"special" means "possibly unexpected" or in the case of $() "you need to
read the documentation to know what it does". As I wrote in my reply to
Richard, I also use the $ to mark variables which are declared and
defined "elsewhere", so I consider these "special", too.

* why do I need a special method?

You don't. I just find it convenient to use it. In the case of $() as a
wrapper for document.getElementById, I still have some adjustments in
there (which will be removed in the next revision) to deal with the case
where there's an element with name="foo" and a different element with
id="foo".

Right. Once you remove that workaround, you should deprecate it. And I
wouldn't use "$" as it has no universal meaning at all. It's typically
uses to query by CSS selectors.

This can cause a lot of fun with IE and getElementById, so I
added some checks in the wrapper.

That's a good idea. Personally I prefer to return null if there is an
issue (so the issue will be immediately apparent for those who test
their code in IE). Others iterate through document.all to find the
"right" element.

The reason why I'm going to remove them is that my library is not
intended for "just any code". I've already removed support for quirks
mode and XHTML; I'm going to remove support for IE's name/id confusion
soon; and I'm also going to remove the support for form elements named
"id", "action", "elements", etc.

All excellent ideas. Why support what you don't use?

My scripts will soon only be useful for
people who write their HTML accordingly. It's a non-general-purpose
library

Those are the best kind.

You'll have to read the docs to find out. If you're trying to create an
API where you never need to read the documentation, good luck. I don't
think it's going to happen.

I don't care for the above as it clearly isn't going to be an exact
duplicate of the like-named DOM method. Of course, as is
well-documented, I don't care for CSS selector queries at all anyway.

I do not agree with that. You can never name all methods to completely
describe what they do.

I think you can to some extent (at least for public API's).

The Java people try, and they have some
impressively verbose method names, but when you take a look at the docs,
you'll see a lot of important information that the method name didn't
tell you. Of course, you could go for

appendArgumentToObjectValueExceptIfItsTooLongThrowAMemoryException ...

Looks very enterprisy that way.

Clearly that's a silly extreme, but it doesn't invalidate more moderate
practices.

That's nice and all. Now try that suggestion in a jQuery forum.

Nah, life is too short. They can't even figure out why their
height/width functions are useless as designed. I saw them go around in
circles on that one for days once and nothing came of it. What does it
matter if the gotten dimensions warp the element on sets? How does that
affect them in their Real World?

That
"god damned dollar function" isn't going away anytime soon.

Which one?

You're not
going to "stamp it out". That's what I meant with "good luck".

Yours? jQuery's factory function? Prototype's gEBI wrapper? Hard to
imagine how that character came to be viewed as some sort of prime real
estate. What a mess that has made. All that talk of "playing nice" and
"unobtrusiveness", six billion character combinations available, and
somehow everyone picked that one, all for completely different features.
No conflict indeed.

Sure, but that kind of ruins the purpose of a shortcut. It's a special
case. You'll have to read the docs for that one.

Why is it a shortcut? Because it has less characters than other
function identifiers? Macros really are underrated.

Mind, I'm very careful not to introduce too many special cases. Most of
the code is self-explanatory. The $ function isn't.

That should tip you off that it is a sore thumb.

I think that rules like that are fine, but it's also fine to break them
if you know what you're doing.

You can't get away with no documentation. At the very least, there
would have to be comments in the code. How else would you know what
type of arguments to pass? I don't think reverse Hungarian notation is
appropriate for JS, so comments and/or documentation and/or examples are
required.

 

[David Mark]

Quite likely. I have no idea who came up with the idea first.
Prototype.js is where I first saw it, and for a few years after that, I
had an attribution in the comments to that effect.


I understand what you're saying, and I agree in principle. I suppose my
preference for short function names for commonly used tasks is related
to my usual work environment. Unix has an abundance of short and cryptic
commands, and I'll readily admit that this is an acquired taste; but the
names in the library fit in well with my work environment and that of
the few other people who ever touch the JS stuff in our projects. Most
of the methods and properties have nice, descriptive names, like
sendAsyncRequest, getNumPending, fullName, lastUpdate, etc. The ones
which are used very frequently tend to be shorter: "mkEle" will create a
DOM element, "tags" is a wrapper for getElementsByTagName, and so on.

One of the reasons why we don't have the One Perfect Ultimate JavaScript
Library is that different approaches work for different people. Some
people like jQuery, some prefer MooTools or Dojo, and some prefer what
I'm writing for them - not least because they appreciate the shortcuts.

And all of those people who prefer Dojo, jQuery or MooTools have at
least one thing in common: delusion. I think my position on jQuery is
well known, but it is a masterpiece compared to Dojo and MooTools (as
well as Prototype). The latter libraries are just hacks piled on hacks,
"enabled" by UA sniffing. It would be madness to pile anything on top
of such structures (unless one has time to keep a constant vigil over
them, returning to rewrite them to fit each new maddeningly incompatible
upgrade and chopping off a chunk of their user base each time).

The end-users just don't follow these projects (for obvious reasons), so
they don't know that Dojo 1.4 - for example - breaks Opera 9 (another
example). And next year they'll wipe out Opera 10 and claim to only
"care" about v11. Will the end-users get that message (and even if they
did, would/could they upgrade their browsers?) They don't even know
what Dojo is. Such failures happen over and over and I am really
surprised that anyone would continue to use such things (does anyone
still drive those late 70's Pintos that blew up on minor collisions?)
It's not just about technical ignorance. A small child could spot the
similarity to Wile E. Coyote's endless failings. More mature readers
should think of Sisyphus.

I know I say the same thing over and over with regard to these issues;
but, of course, there are new readers every day. I mention this to head
of replies of "aw, why don't U write a blog". Why doesn't somebody else
write a blog?

Naming collisions can only occur when there is more than once "source"
of scripts. When I'm the only person creating scripts in an application
there's no need to be afraid of collisions.

I'm not familiar enough with jQuery to know what the "no conflict stuff"
you mentioned is. They're playing a very different game than I.

It's their "solution" to the ridiculous problem they created when they
chose "$" for their silly one-size-fits-all factory (previously a
constructor) function, despite the fact that Prototype was already in
widespread use at the time. The two functions do completely different
things, so it's pretty much insanity at work. And the "popularity" of
this character is beyond explanation. Everyone wants to use "$". Why?
I've asked and never got an answer that approached lucidity.

That is a legitimate concern, especially with a function name like "$".
It's also the reason why no "$" function is created by default in the
hodgepodge of scripts I sometimes call a library. If no other external
scripts are used, it's safe to create the "$" alias, but that's the
responsibility of the library's user (= me, 90% of the time).


Except that those external identifiers could just as well be declared in
a static HTML file. I doubt that's what the spec authors had in mind
when they wrote "mechanically generated".


Yes, obviously. Still, that's generated code by any definition. These
tools are creating new identifiers, and they're not using the dollar
sign.

The specs don't say they must use it (just that humans should not).

I'm not aware of any other software which does.
Anyway, even if they're creating new identifiers in the global scope
(which the minifiers usually don't, except for the Closure Compiler)
there are better ways to avoid collisions than relying on the $dollar.

Yes, that "Compiler" is basically a years-old port of Dojo's builder,
warts and all. Needless to say, it's a disaster waiting to happen to
anyone who buys into it (as is Dojo). Reading forum posts related to
mangled code underlines this clearly. Why do people punish themselves
like that? There are perfectly good minifiers out there (e.g. YUI's is
very good, despite the name) and simple shell scripts (e.g. batch files)
are all that is needed to concatenate files. Granted, depending on the
size of the application and context, such scripts can get pretty
involved; but the idea that the Dojo people are suited to write the
perfect shell script for every possible case is laughable. I mean, look
at their scripts. They fail even before the mangling process.

That would have been the intended
use case of the dollar-identifiers, [snip]
but it hasn't caught on, and so the
suggestion was dropped in ES5.

It was almost certainly not its use (or non-use, if we accept "hasn't
caught on") with machine generated code that provoked the change in
ES5. After all, how could the ECMA committee know the extent to which
the $ symbol is or is not used in mechanically generated code?

One single example of a code generator which actually used the dollar
prefix would probably have helped ;-) I haven't heard of any; which
doesn't mean they don't exist, just that they've managed to evade my
radar. But I agree with your next paragraph...

It is much more realist to suppose that the ECMA committee observed
that the $ symbol had been employed in numerous 'popular' libraries,
was then in widespread use for a huge variety of other reasons (and
suggested meanings), and so recognised that the ability to employ it
to signify mechanically generated code had been neutralised. Basically
a recognition that the horse had bolted, and given that there was no
longer any point in keeping a stable for it.

... that this was likely the reason to drop the recommendation. AFAIK,
there was never any serious use of the $ prefix for automatically
generated code, and since it's been (ab)used for other purposes, keeping
the recommendation would have been useless.

...
The problem with 'special cases' is that there are many, and they
start to risk overlapping as their number increase. Apparently JQuery
developers, for example, have been encouraging the use of a leading $
symbol to indicate a variable or property name that holds a reference
to a JQuery object (the object returned from calls to - $() -). That
doesn't seem such a bad convention in the context of JQuery code.
Another suggested convention was to use a leading $ symbol to indicate
variable that held string values (apparently inspired by the syntax of
some other programming language, and proposed by an individual who
couldn't see that some of the values he was assigning to these
variables were actually numbers, undermining the notion form the
outset). VK proposes a 'convention' where a leading $ symbol get used
in property names (but not in any sort of consistent way over time).
In any single context any one such convention can be usefully
employed, but try mixing them together and the outcome is that each
becomes useless on it own and acts to confuse developers more familiar
with any other.

I realize that this is not very Web2.0 of me, but I'd have to say: so
don't mix incompatible libraries, or incompatible concepts.

Web2.0 has no real meaning, though it has become synonymous with abject
futility (mostly due to the cited strategies). Who could have thought
that mashing up incompatible, inept and convoluted blobs of JS in a
document would lead to catastrophic failures. And who could think
that such things will ever replace proprietary desktop and mobile
applications? Well, I suppose the asylums are full of such people by
now (and more are on the way). Let's hope they stay there.

They all
have their "special" cases. If I were to include several different
libraries on one page, how would I keep their "special" cases separate
from mine? I can't. I can't even keep their "special" cases separate
from each other. My solution is to keep possible conflicts to a minimum,
but not to worry too much about the rest.

But how do you keep conflicts to a minimum by choosing "$" as an
identifier. ISTM that's the end of the game right there.

Yeah, well that was a little too special for me, too. I still haven't
found out which library he's using (I thought it was jsolait at first,
but it isn't). I'm really curious about this, if anybody recognized this
schema, please tell me.


Summary: I use $ signs for variables which are defined outside of a
"library", and optionally for a $() function when I'm the only player in
a document. I don't really see a problem here (except for the
non-semantic shortcut name, which is a matter of taste).

Tastes really bad.

 

[Scott Sauyet]

[ ... ] And the "popularity" of this character is beyond
explanation.  Everyone wants to use "$".  Why?  I've asked
and never got an answer that approached lucidity. [ ... ]

I'm not sure how lucid their reasoning is, but the answers I've heard
have to do with the fact that it is

1. short
2. easy to spot when scanning source code
3. memorable

#1: It certainly is short, and it has a real advantage there over
"YAHOO.util.Connect...". But there are plenty of short identifiers
available, and "j", "m", "p", and "y" are all easier to type than
"$". Perhaps there should be an auction of one-character identifiers
for JS libraries!

#2: This is a nice feature when you're trying to *remove* some
libraries from an application! I don't see why one library should be
any easier to scan for than another or than my own code. I've
actually used a short identifier for precisely the opposite reason. I
often use "_" for a curry function, trying to make the currying as
visually unobtrusive as possible:

var myCurryabledFunction = _(function(arg1, arg2) {...});

#3: Really? Is "$" any more memorable than "Y", "y" or some such? I
think it really was Prototype-envy that started the widespread use.
When it just gets used for document.getElementById or some obvious
wrapper to that the way Prototype does, I don't think it does any
harm. I swear, though, every jQuery newcomer gets bitten often when
trying

$("myElementId").doSomething();

instead of

$("#myElementId").doSomething();

So even if it's memorable as a symbol, the syntax and even the
semantics are not.


And let's not get started on the umpteen different meanings that
jQuery has for the "jQuery" function and it short, scannable,
memorable alias "$"!

 

[David Mark]

[ ... ] And the "popularity" of this character is beyond
explanation. Everyone wants to use "$". Why? I've asked
and never got an answer that approached lucidity. [ ... ]

I'm not sure how lucid their reasoning is, but the answers I've heard
have to do with the fact that it is

1. short

Well, sure. So is any one character identifier. But other than i, j
for loops, they are mostly ill-advised.

2. easy to spot when scanning source code
Eh.

3. memorable

Memorable as what? In the typical case, it reminds developers of how
much money they are wasting (e.g. rewriting Prototype apps).

#1: It certainly is short, and it has a real advantage there over
"YAHOO.util.Connect...".

As demonstrated in the My Library examples and add-ons, the best way to
deal with that is:-

var attachListener = API.attachListener;
var setOpacity = API.setOpacity;

if (attachListener && setOpacity) {

// App that requires events and fading goes here

}

But there are plenty of short identifiers
available, and "j", "m", "p", and "y" are all easier to type than
"$".

Yes, j is often used for nested loops (i is the first choice for the
outer loops). The y goes with x for math functions. Not sure what you
might use m and p for (perhaps more deeply nested loops). Best not to
use any of them to describe functions though.

Perhaps there should be an auction of one-character identifiers
for JS libraries!

A clearinghouse you mean? Well, if only common sense had prevailed back
around the start of the Ajax madness. How did they all manage to land
on the same "prime" location. I wasn't following Ajax at all at the
time, so I don't know. If I had been around, I would have certainly
tried to talk them out of a lot of things that are now seen as "standards".

#2: This is a nice feature when you're trying to *remove* some
libraries from an application! I don't see why one library should be
any easier to scan for than another or than my own code. I've
actually used a short identifier for precisely the opposite reason. I
often use "_" for a curry function, trying to make the currying as
visually unobtrusive as possible:

But the $ character? Which library does it go with? ISTM they all use it.

var myCurryabledFunction = _(function(arg1, arg2) {...});

Dear God. Looks like a typo to me.

#3: Really? Is "$" any more memorable than "Y", "y" or some such? I
think it really was Prototype-envy that started the widespread use.

I imagine so. How anyone could envy that thing is what I want to know.
It's been panned here from the start (and inexplicably that never
changed as the authors seem to have blinders on).

When it just gets used for document.getElementById or some obvious
wrapper to that the way Prototype does, I don't think it does any
harm.

Last I checked, Prototype did all sorts of bizarre hacks in that
function. Doesn't it augment the element, at least in IE? Same for
MooTools I think. Beyond belief really.

I swear, though, every jQuery newcomer gets bitten often when
trying

$("myElementId").doSomething();

instead of

$("#myElementId").doSomething();

That's one of the things I was getting at before about using it as a
plain vanilla gEBI wrapper.

So even if it's memorable as a symbol, the syntax and even the
semantics are not.
Right.



And let's not get started on the umpteen different meanings that
jQuery has for the "jQuery" function and it short, scannable,
memorable alias "$"!

Yes, the bizarre, monolithic API design is beside the point.

 

[Thomas 'PointedEars' Lahn]

Please read it yourself, and then kindly point me to any any instance of
a dollar sign used outside of strings, and not related to regular
expressions (including the RegExp object).

We can see several common fallacies here:

1. Demanding negative proof: You have stated that there is no potential
for ambiguity in regular expressions, but you demand that *I* provide
proof to the contrary.

2. Moving the goalpost/raising the bar: You state that there is no potential
for ambiguity of `$' *in regular expressions*, and when I refer you to
TFM (i.e., the ECMAScript Language Specification) as I was so kind to
interpret this as "involving methods that can be used with regular
expressions"), you demand that I provide proof for "a dollar sign used
outside strings, and not related to regular expression (including the
RegExp object)." which is a different, greater requirement.

3. Straw man argument: I have never stated any of this, you have.

This reply is vague enough to be practically useless.

No, its purpose was to make you think about your faulty generalization
(ISTM a variant of Loki's Wager).

I didn't ask the question,

You asked:

| WHAT are the reasons, besides Ecma 262 R3 Section 7.6, that
| make beginning identifiers with a $ unwise?

Why have you not considered that the "Yes" answer applied to the first part
of the or-question, too, or exclusively to it? You do know what a logical
`or' is, don't you?


PointedEars

 

[Lasse Reichstein Nielsen]

We can see several common fallacies here:

1. Demanding negative proof: You have stated that there is no potential
for ambiguity in regular expressions, but you demand that *I* provide
proof to the contrary.

Uhm, no. That's asking you to provide proof of a positive (or disproof
of a negative).
You claimed the positive: That there is potential for ambiguity, but
gave no examples to support your claim.
He said that he doesn't see any potential for ambiguity.
You claim that TFM supports you, but again omits specifics that can
be used to support your claim.

So far, your, positive, claim has been unsupported.

2. Moving the goalpost/raising the bar: You state that there is no potential
for ambiguity of `$' *in regular expressions*, and when I refer you to
TFM (i.e., the ECMAScript Language Specification) as I was so kind to
interpret this as "involving methods that can be used with regular
expressions"), you demand that I provide proof for "a dollar sign used
outside strings, and not related to regular expression (including the
RegExp object)." which is a different, greater requirement.

No.
You said that $ has a meaning in several context.
He said that he couldn't see any such contexts apart from regular expressions.
I.e, he sees only one context where $ has meaning: Regular expressions.
And he then sais that there is no potential for ambiguity with the $'s used
with regular expressions. That amounts to:
1. There is no potential for ambiguity with the $'s used with regular
expressions.
2. There is no potential for ambiguity with $'s used in contexts other
than regular expressions (since there are none).

Adding the "outside of strings" is really only stating the obvious
(i.e., don't be daft and start talking about string contents, because
that's arbitrary text and can be used to argue for anything). If
anything, it should be obvious that the contents of comments is also
irrelevant to the potential of ambiguity of using "$" in *code*.
If the only examples you can find of "potential ambiguity" in TFM
is with string contents, fess up and admit it, so we can ignore it.

But just to actually RTFM (5ed): The "$" character is only used as:
- allowed character in identifiers.
- reserved character in URIs (so no chance of ambiguity there).
- with regualar expressions (as assertion in RegExp syntax and in
replacement patterns).

If the claim is that there is no potential for ambiguity with the uses
related to regular expressions.
There is obviously no potential for ambiguity with URI strings, since
$ may not even occur there.
There is no other uses of "$" in TFM, so what the blazes are you
talking about when you say RTFM?

3. Straw man argument: I have never stated any of this, you have.


No, its purpose was to make you think about your faulty generalization
(ISTM a variant of Loki's Wager).

It failed its purpose. Your one-word replies are generally useless.
They allow you to state your opinion, but fail completely at giving
any support for it. You might as well be shouting at the wind.
And just to put it straight: it does not make you look clever.

You asked:

| WHAT are the reasons, besides Ecma 262 R3 Section 7.6, that
| make beginning identifiers with a $ unwise?

Why have you not considered that the "Yes" answer applied to the first part
of the or-question, too, or exclusively to it? You do know what a logical
`or' is, don't you?

Are you aware that when people ask a question involving the word "or" in
natural language, they aren't asking for a mathematical logical answer[1],
but for which option is the correct one?

/L
[1] Well, technically, it might be considered intuitionistic logic,
since they want a *constructive* answer

 

[Thomas 'PointedEars' Lahn]

We can see several common fallacies here:

1. Demanding negative proof: You have stated that there is no potential
for ambiguity in regular expressions, but you demand that *I* provide
proof to the contrary.

Uhm, no. That's asking you to provide proof of a positive (or disproof
of a negative).
You claimed the positive: That there is potential for ambiguity, [...]

No, I did not.

No.

You are wrong.

You said that $ has a meaning in several context.
Yes.

He said that he couldn't see any such contexts apart from regular
expressions. I.e, he sees only one context where $ has meaning: Regular
expressions. [...]

And "regular expressions" do _not_ imply "the RegExp object" or "strings".

3. Straw man argument: I have never stated any of this, you have.

See?

You asked:

| WHAT are the reasons, besides Ecma 262 R3 Section 7.6, that
| make beginning identifiers with a $ unwise?

Why have you not considered that the "Yes" answer applied to the first
part of the or-question, too, or exclusively to it? You do know what a
logical `or' is, don't you?

Are you aware that when people ask a question involving the word "or" in
natural language, they aren't asking for a mathematical logical answer[1],
but for which option is the correct one?

Red herring.


PointedEars