Matt Kruse wrote:
Quote:
Richard Cornford wrote:
Quote:
>The spec says "The dollar sign is intended for use only in
>mechanically generated code", which is neither a suggestion
>nor an order, it is an explanation of why a character that did
>not need to be included has been included.
>
It was _intended_ for that use. Not an order. So if people want to
treat it differently, they may.
>
Quote:
>Why would "Selector" be a name for a wrapper round - getElementById
>-? Why would - $ - be a better abbreviation than 'S'?
>
I'm not arguing at all that $ was a good choice for function name.
It is not a good choice, it has no inherent meaning and instead relies
on an association that is not really equivalent, not universal and is
contrarily to an established expectation.
Quote:
Just that it got picked, it became popular, and is now pretty
well recognized and used. Prototype, JQuery, Moo, etc all
use it.
Bad ideas often propagate.
It has been observed in the past that individuals who seem most
knowledgeable about the application of javascript to browser scripting
are not particularly in favour of the notion of general libraries (at
least not in the form exemplified by code such as Prototype.js). The
people who write these libraries don't (possibly cannot) see why, from
their perspective libraries are the obvious approach to code re-use. But
having written something that gains the popularity of Prototype.js they
are maybe trapped in a vicious circle. They cannot move on and they
cannot correct their mistakes. So all they can do is justify them and
elaborate them. Prototype.js is way to complex for what it does, way too
indirect (very un-javascript) and very inefficient, but those aspects of
it are far to fundamental to be fixed. If it were taken as a learning
exercise and abandoned now its author's next effort could be orders of
magnitude better (the third might even be good, then comes the epiphany
when you understand that the general library concept is fundamentally
flawed). None of this can happen, people are writing books devoted to
Prototype.js and after that what code author is going to be able to come
out and say the whole thing was an embarrassing mistake (how many egos
are strong enough to do that).
I suspect a similar thing happened to you (to some extent). You may
recall my saying that when I started in web development I was impressed
with you libraries. We are now at a point where you admit to learning
from me (even, I think, starting to see merits in my re-usable code
design strategies), which means at some point along the path I passed
you, which may in turn suggest that you spent rather longer than you
should have standing still ("resting on your laurels", as they say).
(Direction not withstanding) at least you are now moving forward again.
Quote:
Quote:
>In practice wrapping a - $ - function around - getElementById -
>(however loosely) is more of a nod toward the Microsoft notion that
>IDed DOM elements should be made available as properties of the
>global object (effectively pre-defined global variables).
>
I think it is more tied to resolving, or dereferencing, as you
noted above. Which makes it a logical choice, IMO, unconnected
to any IE behavior.
Except with IDed DOM Elements it is not de-referencing (except in a very
loose sense), it is looking them up in a tree structure by ID.
Quote:
Quote:
>Several times over the years I have asked you to state whether
>you think the client of a professional web developer has a
>reasonable right to expect that developer to possess the
>technical skills that they are selling. You have never answered
>the direct question.
>
I believe I have. Of course they have a right to expect that.
No, that is the first time you have come out an actually said as much.
Quote:
But in the Real World, that doesn't mean they will get it.
Maybe not, but it is the expected relationship between a client and a
professional that they employ. And so it defines what is expected of the
professional before they label themselves as such.
Quote:
And whether they actually get it usually depends on the price
they are willing to pay.
I don't think that paying a high price guarantees anything. If someone
is brazen enough to be selling skills they do not posses they may well
be brazen enough to charge well over the odds for what they are not
providing. Indeed, having the balls to charge an excessive fee may be
seen as reassuring to the client.
Quote:
It's not black and white. Technical skills are a sliding
scale, so you cannot say that someone either has Javascript
skills or doesn't.
Well, you can say when they don't with certainty. Judging the speculum
of those that do is another matter, thought there are stages in
understanding that we have all been through and so recognise others who
have not passed that point themselves. A trivial example might be
someone - eval -ing a constructed dot-notation property accessor. We all
know that that is something that you never do once you have got past the
basics, so when you see it you know something about the author or code
that uses it.
Quote:
There is far more Javascript to be written than exist people
with your qualifications to write it. If everyone had to live
up to your standards before writing any js code, very little
would be written.
But the vast majority of javascript code doesn't need someone with my
"qualifications" to write it. In the past many people started off with
relatively simple form validation and image roll-over effects, neither
of which need much understanding of javascript to do well (though they
can still be done catastrophically badly).
Quote:
You may argue that this would be preferrable. I would argue
that it would not be.
In what way would it not be preferable for everyone authoring javascript
to have a good understanding of the subject and extensive pertinent
experience? It may not be practical but it has got to be preferable if
it were practical.
Quote:
Quote:
>Here you are arguing that because a mass or individuals follow a
>particular course (whether motivated by choice, fashion, ease,
>perceived familiarity or whatever else) then that course is
>acceptable (regardless of its consequences).
>
First, there are no real 'consequences' of using $ in
identifiers in javascript.
There is considerably expanded potential for people to write more
obscure source code and think that they are justified in doing so.
Quote:
Other than possibly confusing some javascript experts, who
probably won't be looking at code using $ anyway.
Having people not looking at code that has - $ - symbols to the greatest
extent possible is a desirable outcome. Reserving the symbol for a
general (but relatively uncommon) context where its appearance is a
warning that there is another aspect to the code that should not be
ignored is the point of following the convention.
Quote:
Second, I didn't argue that whatever "the masses" choose is
acceptable. Rather, that you must adapt to the Real World,
and the masses choose the Real World.
Adapting to a "real world" is no necessarily going along with it. Indeed
there have been many things in the "real world" that should never have
been gone along with (totalitarian government being an obvious example).
Quote:
If things are moving in a direction that you disagree
with, you can either adapt or you can stay firm and
become irrelevant.
Becoming irrelevant is not necessarily the consequence of not following
a crowd.
Quote:
Stick your head in the sand if you wish. The world
will move on, despite your protests of its general
incompetence.
Protestations of general incompetence are not going to change anything
(even if they explain some things) but reasoned arguments for a
particular position may well influence individuals, and if sufficient
individuals are influence then the result may be to change the outcome
of things.
Quote:
You always focus on yourself - but you're the rare exception.
I don't know about always focusing on myself, but I do have pertinent
experience. Inevitably, before I started working in web development
there was a time when I knew nothing about the subject, and the earliest
javascript I wrote is so bad, looking back on it, that it is
embarrassing to think about it now (and it did all of the things that I
now recognise as bad, including probably directly costing the people who
used it income). That is, I have been as bad a web developer as any (in
terms of technical ignorance at least, I have not been as idle,
disinterested, self-satisfied, dishonest, etc. as some). That means that
I am not necessarily a rare exception, just someone at a point on a path
where few have been before but many yet choose to follow.
Quote:
You can code everything yourself. Fantastic. I can't imagine
you would use a library, because you could easily write your
own code.
What is a library? For the last couple of years I have been working on
frameworks for web applications. From one point of view that is a
library (indeed Yahoo distribute their application framework in the
guise of a general-purpose library, though that may just be so they can
get it vigorously tested (even debugged) at negligible internal cost).
Quote:
But when it comes to "the masses" and what people should do
who lack the time and skills that you have, your conclusions
are very idealistic and not very practical.
Here you go again. You admit that the client has a reasonable
expectation that the professionals they hire should posses the skills
pertinent to their profession, but then excuse those 'professionals' for
not having the time or inclination to learn those skills.
Quote:
It's like politicians who talk
about lowering taxes, feeding the hungry, saving the environment,
ending war, etc - sounds great! But what are you _really_ going to
do? Because we all know the idealistic talk is just talk.
>
Quote:
>Considering that you publish a javascript 'best practices'
>page (and frequently refer others to it) isn't that a bit
>of an inconsistent position?
>
I don't believe so. You've yet to put forward any convincing
argument to me that $() is an unacceptable choice for a
function name,
I am yet to convince you, others may see things differently.
Quote:
other than pointing to specs that say the $ was intended
for something else.
And to point out that the name has no inherent meaning (beyond the
convention in the spec and its use as a currency symbol in the wider
world), that its associations with the dollar symbol's use in other
languages does not really fit with how it is being employed in this
context, and that abandoning the convention and allowing it in this
context means allowing the use of the dollar symbol in any other
contexts, with the consequent general obscuring of javascript source
code as individuals adopt their own personal 'conventional' meanings
attached to a symbol that adds nothing to Identifier clarity in itself.
Quote:
Well, if everyone stuck to what things were intended for, we
certainly wouldn't have any innovation in the world.
What "innovation" do you propose could follow from abandoning a common
naming convention in a programming language? It is not as if choosing to
write clear source code gets in the way of actually doing anything with
the language. The computers don't care at all what names we may or may
not use as Identifiers, so long as the syntax rules are not broaden.
Quote:
I need a
stronger argument than "that's not what they intended!"
And I don't (even though other arguments exist). I lose nothing from
following the convention from the language specification, and I may gain
something (though more likely my employer will see the real benefits).
Quote:
Quote:
>to a large mass of 'web developers' VK (apparently) looks
>impressive.
>
Which is the Real World. Which is why libraries and frameworks
must exist. So people like VK cannot be seen as experts, nor
their "skills" needed.
VK is about bamboozling people who don't know any better. You don't
address that by letting people get away with never learning to know
better, quite the reverse.
Quote:
Because any average Javascript developer can
use a solid, robust, cross-browser, standards-compliant library
that helps them accomplish their task without having a deep
understanding of the inner workings.
And Prototype.js is not a solid, robust, cross-browser,
standards-compliant library (well, I might accept "solid", very solid,
one very solid lump of code).
Quote:
Quote:
>Consider:-
>alert(this.$.$.id);
>
That's not absurdly clear to you?! ;)
It was not even clear to the individual who wrote it. The object
referred to by - this - was the same object as was refereed to by the
second - $ - and so the whole thing could have been replaced with -
alert(this.id); -. If the original property accessor had used meaningful
Identifiers, a more context specific equivalent of -
this.jsObject.domElement.id - for example, then it might even have been
obvious to its own author that he was going around in pointless circles
(and the memory-leaking tight circular reference between a DOM node and
JS object may also have been apparent (though at the time VK was
swearing that IE's circular reference problem was not real, despite
repeatedly being shown otherwise)).
So, absurd yes, clear no.
Richard.
