By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,911 Members | 1,192 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,911 IT Pros & Developers. It's quick & easy.

How a delete a object from DOM ?

P: n/a
I have a 4row x 1col table, I would like to drop all the content of row
three.
Since Mac IE5.2 does not suppport deleteRow method,
I have also try to set the innerHTML=''; but it does not work.

How can I delete the node from DOM in other way?
Thanks.

Aug 3 '06 #1
Share this Question
Share on Google+
22 Replies


P: n/a
Cylix wrote:
I have a 4row x 1col table, I would like to drop all the content of row
three.
Since Mac IE5.2 does not suppport deleteRow method,
I have also try to set the innerHTML=''; but it does not work.

How can I delete the node from DOM in other way?
Thanks.
Oh, Sorry, I found the way to do so already ...

Suppose "row" is the object going to delete:
row.parentNode.removeChild(row);

Aug 3 '06 #2

P: n/a
Ray
Cylix wrote:
I have a 4row x 1col table, I would like to drop all the content of row
three.
Since Mac IE5.2 does not suppport deleteRow method,
I have also try to set the innerHTML=''; but it does not work.

How can I delete the node from DOM in other way?
Thanks.
Can't you remove the <TRfrom the <TBODY>? E.g. for the third row, if
tbody refers to the TBODY element:

tbody.removeChild(tbody.childNodes[2]);

Ray

Aug 3 '06 #3

P: n/a
Cylix wrote:
I have a 4row x 1col table, I would like to drop all the content of row
three.
Since Mac IE5.2 does not suppport deleteRow method,
I have also try to set the innerHTML=''; but it does not work.

How can I delete the node from DOM in other way?
Thanks.
Two-line function library:
<script>
function $(id){return document.getElementById(id);}
function $del(id) {$(id).parentNode.removeChild($(id));}
</script>

Usage:
<script>
$del(ObjectIDString);
</script>

Methods are lame because you have to repeat yourself. They are fine for
toolkits but not applications, which should be created in plain english
or as close as you can get.

hth

http://darwinist.googlepages.com/htmldesktop.html

Aug 3 '06 #4

P: n/a
da*******@gmail.com wrote:
<snip>
Two-line function library:
<script>
function $(id){return document.getElementById(id);}
function $del(id) {$(id).parentNode.removeChild($(id));}
</script>
<snip>

As the specification for javascript (ECMA 262) explicitly states that
Identifiers beginning with the - $ - symbol are intended to signify
machine generated Identifiers it is poor javascript design to write code
that uses such identifiers in non-machine generated Identifiers. All
real javascript programmers can be expected to be familiar with that
formal convention and so bring expectations to their reading of code
that uses Identifiers that start with - $ -, which, when disappointed,
will result in wasted time and effort, thus needlessly increasing code
maintenance costs. (Not to mention the impact of using such
self-evidently obscure Identifiers in code).

Though in practice wrapping calls to - removeChild - in two function
calls, and requiring that Elements referenced have ID attributes would
not be a good idea anyway. In most cases the desire to remove an element
from the DOM implies already having a reference to that element so its
parent's - removeChild - method could be more easily called directly,
and the impact of giving elements ID attributes on IE's memory leak
problem would suggest minimising their use in any event.

Richard.
Aug 3 '06 #5

P: n/a
Richard Cornford wrote:
da*******@gmail.com wrote:
<snip>
Two-line function library:
<script>
function $(id){return document.getElementById(id);}
function $del(id) {$(id).parentNode.removeChild($(id));}
</script>
<snip>

As the specification for javascript (ECMA 262) explicitly states that
Identifiers beginning with the - $ - symbol are intended to signify
machine generated Identifiers it is poor javascript design to write code
that uses such identifiers in non-machine generated Identifiers. All
real javascript programmers can be expected to be familiar with that
formal convention and so bring expectations to their reading of code
that uses Identifiers that start with - $ -, which, when disappointed,
will result in wasted time and effort, thus needlessly increasing code
maintenance costs. (Not to mention the impact of using such
self-evidently obscure Identifiers in code).
I disagree, i find it highly intuitive to group functions which handle
dom-related elements, and it works across browsers.

You can talk in vague theory about obscure code and confused
programmers but I'm not convinced. I challenge you to find an obscure
line in this entire windowing system:
http://darwinist.googlepages.com/htmldesktop.html
Though in practice wrapping calls to - removeChild - in two function
calls, and requiring that Elements referenced have ID attributes would
not be a good idea anyway. In most cases the desire to remove an element
from the DOM implies already having a reference to that element so its
parent's - removeChild - method could be more easily called directly,
and the impact of giving elements ID attributes on IE's memory leak
problem would suggest minimising their use in any event.
An important consideration, and one of which I was not aware. On the
other hand, it runs like lightning in firefox and microsoft will
readily admit their browser update is long overdue. I'm not
particularly interested in coding to the bugs of a product whose
manufacturers don't even pretend it's good anymore.

$del("id"); is quick and easy and allows you to be more productive.
Richard.
Aug 4 '06 #6

P: n/a
da*******@gmail.com wrote:
Richard Cornford wrote:
>da*******@gmail.com wrote:
<snip>
Two-line function library:
<script>
function $(id){return document.getElementById(id);}
function $del(id) {$(id).parentNode.removeChild($(id));}
</script>
<snip>

As the specification for javascript (ECMA 262) explicitly states that
Identifiers beginning with the - $ - symbol are intended to signify
machine generated Identifiers it is poor javascript design to write
code that uses such identifiers in non-machine generated
Identifiers. All real javascript programmers can be expected to be
familiar with that formal convention and so bring expectations to
their reading of code that uses Identifiers that start with - $ -,
which, when disappointed, will result in wasted time and effort,
thus needlessly increasing code maintenance costs. (Not to mention
the impact of using such self-evidently obscure Identifiers in code).

I disagree,
The existence of the convention in the language's specification is fact.
i find it highly intuitive to group functions which handle
dom-related elements, and it works across browsers.
What 'works' is not really an issue. Making up your own conventions is
your choice, but disregarding well known and established conventions
will make your personal conventions act against the wider readability of
your code for programmers who are familiar with the well known and
established conventions.
You can talk in vague theory about obscure code and
confused programmers but I'm not convinced.
Working to programming conventions is such a sensible idea that software
houses tend to formalise a set of conventions and insist that all their
programmers work to those. They don't do that because following
conventions represents a 'vague theory', they do it because it reduces
their code maintenance costs by making code quicker to read/understand.
As a result there are sets of well established conventions for most
languages coming from various sources, and conventions that are found in
the pertinent language's specification are likely to be common in use.
I challenge you to find an obscure
line in this entire windowing system:
http://darwinist.googlepages.com/htmldesktop.html
Don't be silly.
>Though in practice wrapping calls to - removeChild - in
two function calls, and requiring that Elements referenced
have ID attributes would not be a good idea anyway. In most
cases the desire to remove an element from the DOM implies
already having a reference to that element so its parent's
- removeChild - method could be more easily called directly,
and the impact of giving elements ID attributes on IE's
memory leak problem would suggest minimising their use in any
event.

An important consideration, and one of which I was not aware.
On the other hand, it runs like lightning in firefox and
microsoft will readily admit their browser update is long
overdue.
Overdue as it may be, commercial browser scripting has to accommodate IE
browsers. If you would prefer to work in some personal 'hobby' market
that is up to you but that does not mean that proposing practices that
are not suitable in a commercial environment is a good idea.
I'm not particularly interested in coding to the bugs of a
product whose manufacturers don't even pretend it's good
anymore.

$del("id"); is quick and easy and allows you to be more
productive.
What it does for you is not relevant. It will potentially get in the way
of the productivity of a third party knowledgeable javascript programmer
attempting to maintain your code as they will have to spend effort
determining that this apparently machine generated Identifier is not
actually machine generated (and then expend effort re-writing your code
to eliminate the faulty Identifiers).

The overall impact of having to stuff a document with an excessive
number of unique element IDs may be less apparent, but it will act to
hinder development in the longer term.

Generally, javascript is easier to write, maintain and understand when
it uses references to objects directly instead of indirectly referring
to them with string values representing names and IDs.

Richard.
Aug 4 '06 #7

P: n/a
Richard Cornford wrote:
da*******@gmail.com wrote:
Richard Cornford wrote:
da*******@gmail.com wrote:
<snip>
Two-line function library:
<script>
function $(id){return document.getElementById(id);}
function $del(id) {$(id).parentNode.removeChild($(id));}
</script>
<snip>

As the specification for javascript (ECMA 262) explicitly states that
Identifiers beginning with the - $ - symbol are intended to signify
machine generated Identifiers it is poor javascript design to write
code that uses such identifiers in non-machine generated
Identifiers. All real javascript programmers can be expected to be
familiar with that formal convention and so bring expectations to
their reading of code that uses Identifiers that start with - $ -,
which, when disappointed, will result in wasted time and effort,
thus needlessly increasing code maintenance costs. (Not to mention
the impact of using such self-evidently obscure Identifiers in code).
I disagree,

The existence of the convention in the language's specification is fact.
I disagree that it will add to net confusion or obscurity.
i find it highly intuitive to group functions which handle
dom-related elements, and it works across browsers.

What 'works' is not really an issue.
Sorry I must have misheard you. Could you say that again?
Making up your own conventions is
your choice, but disregarding well known and established conventions
will make your personal conventions act against the wider readability of
your code for programmers who are familiar with the well known and
established conventions.
Not all conventions are of equal value. It depends on how well any
convention is suited to the task that your code is intended to achieve.
You can talk in vague theory about obscure code and
confused programmers but I'm not convinced.

Working to programming conventions is such a sensible idea that software
houses tend to formalise a set of conventions and insist that all their
programmers work to those. They don't do that because following
conventions represents a 'vague theory', they do it because it reduces
their code maintenance costs by making code quicker to read/understand.
As a result there are sets of well established conventions for most
languages coming from various sources, and conventions that are found in
the pertinent language's specification are likely to be common in use.
There are lots of conventions and they don't always agree.
I challenge you to find an obscure
line in this entire windowing system:
http://darwinist.googlepages.com/htmldesktop.html

Don't be silly.
Don't be puritanical.
Though in practice wrapping calls to - removeChild - in
two function calls, and requiring that Elements referenced
have ID attributes would not be a good idea anyway. In most
cases the desire to remove an element from the DOM implies
already having a reference to that element so its parent's
- removeChild - method could be more easily called directly,
and the impact of giving elements ID attributes on IE's
memory leak problem would suggest minimising their use in any
event.
An important consideration, and one of which I was not aware.
On the other hand, it runs like lightning in firefox and
microsoft will readily admit their browser update is long
overdue.

Overdue as it may be, commercial browser scripting has to accommodate IE
browsers. If you would prefer to work in some personal 'hobby' market
that is up to you but that does not mean that proposing practices that
are not suitable in a commercial environment is a good idea.
You have much more time to test and optimise for speed if you can
express the initial applicaton at some level higher than the base
toolkit. Methods are lame because they don't know anything about your
application.
I'm not particularly interested in coding to the bugs of a
product whose manufacturers don't even pretend it's good
anymore.

$del("id"); is quick and easy and allows you to be more
productive.

What it does for you is not relevant. It will potentially get in the way
of the productivity of a third party knowledgeable javascript programmer
attempting to maintain your code as they will have to spend effort
determining that this apparently machine generated Identifier is not
actually machine generated (and then expend effort re-writing your code
to eliminate the faulty Identifiers).
a) it's a common practice (ask google if you don't believe me)
b) it makes your code shorter and more readable
c) you can combine it with other useful element functions, like
$make(tagname, id); // make an element
$input(type, name, value, [id]) // make an input
$text(text) // make a text node
d) this approach allows you write applications more quickly.
e) you can then optimise for speed in any areas that are script-heavy.
f) most programmers would know it to be a waste of time to rewrite
something that works for style alone
g) In this particular case, nobody would be confused for more than ten
seconds, if at all, after which this function will save them a great
many keystrokes, without a noticable difference in page performance.
The overall impact of having to stuff a document with an excessive
number of unique element IDs may be less apparent, but it will act to
hinder development in the longer term.
So will long and complicated statements, which are inevitable if you
stick as close as possible to the native javascript/dom methods when
writing your applicatoin.
Generally, javascript is easier to write, maintain and understand when
it uses references to objects directly instead of indirectly referring
to them with string values representing names and IDs.
True, but to get the initial reference you often have to use id, and if
you do this many times in a document, on various events for example,
then you're going to get sick of typing document.getElementById() for
such a common task.

Also you could modify $del() to accept either elements(by reference) or
IDs and act accordingly.

---
http://darwinist.googlepages.com/htmldesktop.html
(A free, open-source web-based IDE, windowing system, and desktop
environment, in 31kB of html and javascript.)
Richard.
Aug 4 '06 #8

P: n/a
darwinist wrote:
Richard Cornford wrote:
>da*******@gmail.com wrote:
>>Richard Cornford wrote:
da*******@gmail.com wrote:
Two-line function library:
<script>
function $(id){return document.getElementById(id);}
function $del(id) {$(id).parentNode.removeChild($(id));}
</script>
<snip>

As the specification for javascript (ECMA 262) explicitly
states that Identifiers beginning with the - $ - symbol
are intended to signify machine generated Identifiers it
is poor javascript design to write code that uses such
identifiers in non-machine generated Identifiers. ...
<snip>
>>I disagree,

The existence of the convention in the language's
specification is fact.

I disagree that it will add to net confusion or obscurity.
Perhaps you should try trimming try quotes you reply to so that the
context of your responses is not ambiguous.

Confusion results form disappointing expectations. It is not
unreasonable for someone to read the convention in the language's
specification and expect others to follow it. When you disregard that
convention for no good reason you are going to cause confusion, and
delays and increased maintenance costs while that confusion is resolved.
>>i find it highly intuitive to group functions which
handle dom-related elements, and it works across browsers.

What 'works' is not really an issue.

Sorry I must have misheard you. Could you say that again?
What 'works' is not really an issue. In allowing the inclusion of the $
symbol in identifiers and then asserting that it should only be used at
the start of a machine generated Identifier the specification had no
choice but allow any Identifier starting with a $ symbol to be legal.
The interpreter cannot know that an Identifier has been machine
generated, and so cannot apply special tokenising/parsing rules for
machine generated Identifiers. Using them where they should not be used
is going to 'work', it is just something that should not be done.
>Making up your own conventions is
your choice, but disregarding well known and established conventions
will make your personal conventions act against the wider
readability of your code for programmers who are familiar with the
well known and established conventions.

Not all conventions are of equal value.
No they are not. Conventions are essentially arbitrary, they can all be
disregarded and leave an end result that still 'works'. And there are
numbers of different conventions applying to the same situations and
producing different results. Which conventions get followed is largely a
matter of authority. In a software house there likely are a set of house
conventions for coding in various languages, probably formalised, and
all programming staff are required to conform to those conventions.
However, the set of conventions chosen are not likely to be some
arbitrary notions plucked from the air and imposed as an exercise in
power. They will b chosen because they act to benefit the software
authoring/maintaining process, by making code standard in formal
structure, easily understood and recognisable for what it is. They will
be conventions that the programmers are (more or less) familiar with and
appreciate the motivation for.

The act of specifically stating the convention if the language's
specification pretty much guarantees that any serious javascript
programmer will be familiar with it. From that starting point an formal
coding standards document that overwrites that convention with another
would be ill-conceived.
It depends on how well any convention is suited to the
task that your code is intended to achieve.
Any naming convention could make DOM related method distinct from
others, and may would be less ambiguous themselves, and all others would
avoid facing the reasonable assumption that the convention laid down in
the specification was in use.
>>You can talk in vague theory about obscure code and
confused programmers but I'm not convinced.

Working to programming conventions is such a sensible idea
that software houses tend to formalise a set of conventions
and insist that all their programmers work to those. They
don't do that because following conventions represents a
'vague theory', they do it because it reduces their code
maintenance costs by making code quicker to read/understand.
As a result there are sets of well established conventions
for most languages coming from various sources, and
conventions that are found in the pertinent language's
specification are likely to be common in use.

There are lots of conventions and they don't always agree.
Of course not. If a formal coding standard say everyone will use one
particular style of block indentation that it immediately precludes all
other styles.
>>I challenge you to find an obscure
line in this entire windowing system:
http://darwinist.googlepages.com/htmldesktop.html

Don't be silly.

Don't be puritanical.
In any substantial body of code there will be at least one line that is
totally obscure when taken out of context.

But we are not interested in absolute obscurity but rather relative
obscurity. Your:-

$del("something");

- is inherently obscure, It just needs comparing with alternatives such
as:-

removeDomElementById("soemthing);

In the first case you almost know nothing without the source code for -
$del -, while in the second case the odds are good that the reader does
not have to even go an see what the functions does because its name has
already told them.

<snip>
>>I'm not particularly interested in coding to the bugs of a
product whose manufacturers don't even pretend it's good
anymore.

$del("id"); is quick and easy and allows you to be more
productive.

What it does for you is not relevant. It will potentially get
in the way of the productivity of a third party knowledgeable
javascript programmer attempting to maintain your code as they
will have to spend effort determining that this apparently
machine generated Identifier is not actually machine generated
(and then expend effort re-writing your code to eliminate the
faulty Identifiers).

a) it's a common practice (ask google if you don't believe me)
What is common practice? Using initial $ symbols in javascript code, or
using initial $ symbols to indicate DOM related methods?

First, the vast majority of the javascript code in the world was written
(or copy and pasted) by people who did not really know what they were
doing (and most of the stuff that can be copy and pasted was written by
equally under informed individuals). As a result any appeal to what is
'common practice' is likely an appeal to 'bad practice'.

Initial $ symbols are commonly abused in actual javascript code, but
they certainly are not commonly misused for any single specific purpose.
They can be used to reflect the use of the $ symbol in other languages
(usually with a significant conceptual mismatch), they can be being used
to indicate values of string type, they can be used to indicate values
that should be regarded as internal or private. Indeed you are the first
person I have read proposing that they be used to indicate DOM related
functions. It is in fact this diversity of $ abuses that suggests that
any use outside of the conventions provided in the specification is
unwise, as no other expectation would be common.
b) it makes your code shorter and more readable
Shorter maybe, but shortness at the cost of readability is not a good
trade-off (as shortness can be machine imposed post development). While
readability is precisely what it does not proved. There is no reason for
a reader to see a $ symbol as having anything to do with DOM related
functions, and very good reasons for them to see the $ symbol as having
something to do with machine generation.
c) you can combine it with other useful element functions, like
$make(tagname, id); // make an element
$input(type, name, value, [id]) // make an input
$text(text) // make a text node
Wrapping common code structures into parameterised functions is not an
idea that requires, or justifies, a specific naming convention.
dom_make, dom_input and dom_text being just as possible, and
fractionally less obscure.
d) this approach allows you write applications more quickly.
It is well known that the maintenance costs are always a significant
factor in applications.
e) you can then optimise for speed in any areas that
are script-heavy.
There is no relationship between an ability to optimise for speed and
the use of any particular naming convention.
f) most programmers would know it to be a waste of time to
rewrite something that works for style alone
Most programmers would know enough not to write something obscurely in
the first place.
g) In this particular case, nobody would be confused for
more than ten seconds, if at all, after which this function
will save them a great many keystrokes, without a noticable
difference in page performance.
If you were not even aware of the IE memory leak problem I don't think
you have ever written anything with javascript that qualifies you to
make such statements about performance.

Of all the things that may be 'saved' in software authoring I don't
think anyone would seriously propose that keystrokes are something that
needs worrying about.

>The overall impact of having to stuff a document with an
excessive number of unique element IDs may be less apparent,
but it will act to hinder development in the longer term.

So will long and complicated statements, which are inevitable
if you stick as close as possible to the native javascript/dom
methods when writing your applicatoin.

Well? Replacing re-occurring blocks of code with parameterised function
call is normal and sensible. I would question the reason for wrapping
code in a function when that function itself only contains one line of
code.
>Generally, javascript is easier to write, maintain and understand
when it uses references to objects directly instead of indirectly
referring to them with string values representing names and IDs.

True, but to get the initial reference you often have to
use id,
No you don't. In an event driven system like a web browser the starting
point of code execution is usually attached to the DOM elements of
interest, or they can be recovered from the event object (with elements
that have structural relationships to those elements being recoverable
by reference through the DOM), and if you create an element you have a
reference to it at that point and do not need to get another so long as
you don't prematurely throw it away.
and if you do this many times in a document, on various
events for example, then you're going to get sick of typing
document.getElementById() for such a common task.
I may if I did. A quick text search for '.getElementById(' in all the
60,000 lines of javascript code in the web application I am working on
at the moment shows 220 occurrences.
Also you could modify $del() to accept either elements(by
reference) or IDs and act accordingly.
Given how simple the contents of the actual function is, and the fact
that the programmer should know whether they re dealing with an ID sting
or an object reference at the point of calling the function, it would
probably be better to have two function than have each function call
test and branch.

Richard.
Aug 6 '06 #9

P: n/a
Richard Cornford wrote:
darwinist wrote:
Richard Cornford wrote:
da*******@gmail.com wrote:
Richard Cornford wrote:
da*******@gmail.com wrote:
Two-line function library:
<script>
function $(id){return document.getElementById(id);}
function $del(id) {$(id).parentNode.removeChild($(id));}
</script>
<snip>

As the specification for javascript (ECMA 262) explicitly
states that Identifiers beginning with the - $ - symbol
are intended to signify machine generated Identifiers it
is poor javascript design to write code that uses such
identifiers in non-machine generated Identifiers. ...
<snip>
>I disagree,

The existence of the convention in the language's
specification is fact.
I disagree that it will add to net confusion or obscurity.

Perhaps you should try trimming try quotes you reply to so that the
context of your responses is not ambiguous.
Apologies for not being clear.
Confusion results form disappointing expectations. It is not
unreasonable for someone to read the convention in the language's
specification and expect others to follow it. When you disregard that
convention for no good reason you are going to cause confusion, and
delays and increased maintenance costs while that confusion is resolved.
And I still say this is vague theory when I have presented a practical
example, if an imperfect one, to illustrate just how much "confusion"
would ensue before one sees that $del is delete an element and $make is
make an element and all else in the application is clearer. It's a
style convention, which are project specific, and unenforcable by
interpreters as you say.
>i find it highly intuitive to group functions which
handle dom-related elements, and it works across browsers.

What 'works' is not really an issue.
Sorry I must have misheard you. Could you say that again?

What 'works' is not really an issue. In allowing the inclusion of the $
symbol in identifiers and then asserting that it should only be used at
the start of a machine generated Identifier the specification had no
choice but allow any Identifier starting with a $ symbol to be legal.
The interpreter cannot know that an Identifier has been machine
generated, and so cannot apply special tokenising/parsing rules for
machine generated Identifiers. Using them where they should not be used
is going to 'work', it is just something that should not be done.
If the only practical difference it makes is to how some people
interpret it, then it's a style difference, which has no place in a
language specification. Just cause it's in a spec doesn't mean it
should be followed, when the spec doesn't describe the actual platform
you are writing for.
Making up your own conventions is
your choice, but disregarding well known and established conventions
will make your personal conventions act against the wider
readability of your code for programmers who are familiar with the
well known and established conventions.
Not all conventions are of equal value.

No they are not. Conventions are essentially arbitrary, they can all be
disregarded and leave an end result that still 'works'. And there are
numbers of different conventions applying to the same situations and
producing different results. Which conventions get followed is largely a
matter of authority. In a software house there likely are a set of house
conventions for coding in various languages, probably formalised, and
all programming staff are required to conform to those conventions.
However, the set of conventions chosen are not likely to be some
arbitrary notions plucked from the air and imposed as an exercise in
power. They will b chosen because they act to benefit the software
authoring/maintaining process, by making code standard in formal
structure, easily understood and recognisable for what it is. They will
be conventions that the programmers are (more or less) familiar with and
appreciate the motivation for.

The act of specifically stating the convention if the language's
specification pretty much guarantees that any serious javascript
programmer will be familiar with it. From that starting point an formal
coding standards document that overwrites that convention with another
would be ill-conceived.
Not necessarily, it depends what actual difference it makes.
It depends on how well any convention is suited to the
task that your code is intended to achieve.

Any naming convention could make DOM related method distinct from
others, and may would be less ambiguous themselves, and all others would
avoid facing the reasonable assumption that the convention laid down in
Except manipulating dom objects is so common and important that an
obvious single symbol is very efficient. dom_make takes up more space
on the screen without adding clarity. $make is easier to spot, as well.
>You can talk in vague theory about obscure code and
confused programmers but I'm not convinced.

Working to programming conventions is such a sensible idea
that software houses tend to formalise a set of conventions
and insist that all their programmers work to those. They
don't do that because following conventions represents a
'vague theory', they do it because it reduces their code
maintenance costs by making code quicker to read/understand.
As a result there are sets of well established conventions
for most languages coming from various sources, and
conventions that are found in the pertinent language's
specification are likely to be common in use.
There are lots of conventions and they don't always agree.

Of course not. If a formal coding standard say everyone will use one
particular style of block indentation that it immediately precludes all
other styles.
>I challenge you to find an obscure
line in this entire windowing system:
http://darwinist.googlepages.com/htmldesktop.html

Don't be silly.
Don't be puritanical.

In any substantial body of code there will be at least one line that is
totally obscure when taken out of context.

But we are not interested in absolute obscurity but rather relative
obscurity. Your:-

$del("something");

- is inherently obscure, It just needs comparing with alternatives such
as:-

removeDomElementById("soemthing);

In the first case you almost know nothing without the source code for -
$del -, while in the second case the odds are good that the reader does
not have to even go an see what the functions does because its name has
already told them.
Besides the fact that the this approach makes the programs much
shorter, allowing context to be seen more quickly, anyone browsing the
code ought to have sufficient commentary as to why something is being
deleted, and what it is. An application must be allowed its own
linguistic context in which things like "del" have a known meaning. In
a file-system-based command line it would be assumed it was a file, in
any web-application that's gui heavy, it might mean a gui element. The
$ just makes it even more clear in the context of that particular
project.
<snip>
>I'm not particularly interested in coding to the bugs of a
product whose manufacturers don't even pretend it's good
anymore.

$del("id"); is quick and easy and allows you to be more
productive.

What it does for you is not relevant. It will potentially get
in the way of the productivity of a third party knowledgeable
javascript programmer attempting to maintain your code as they
will have to spend effort determining that this apparently
machine generated Identifier is not actually machine generated
(and then expend effort re-writing your code to eliminate the
faulty Identifiers).
a) it's a common practice (ask google if you don't believe me)

What is common practice? Using initial $ symbols in javascript code, or
using initial $ symbols to indicate DOM related methods?
The latter, to return elements by id or reference. I don't know if many
people use $make and $del and $input and $text, but I liked the idea
and the syntax so much (being a php programmer, which I think a lot of
js programmers are these days), that I extended the idea for my
windowing system.
First, the vast majority of the javascript code in the world was written
(or copy and pasted) by people who did not really know what they were
doing (and most of the stuff that can be copy and pasted was written by
equally under informed individuals). As a result any appeal to what is
'common practice' is likely an appeal to 'bad practice'.
Your primary argument against using the $ to denote dom elements is one
of convention, to avoid confusing people who are experienced
javascript programmers. What if they're experienced in these bad
practices?
Initial $ symbols are commonly abused in actual javascript code, but
they certainly are not commonly misused for any single specific purpose.
They can be used to reflect the use of the $ symbol in other languages
(usually with a significant conceptual mismatch), they can be being used
to indicate values of string type, they can be used to indicate values
that should be regarded as internal or private. Indeed you are the first
person I have read proposing that they be used to indicate DOM related
functions. It is in fact this diversity of $ abuses that suggests that
any use outside of the conventions provided in the specification is
unwise, as no other expectation would be common.
b) it makes your code shorter and more readable

Shorter maybe, but shortness at the cost of readability is not a good
trade-off (as shortness can be machine imposed post development). While
readability is precisely what it does not proved. There is no reason for
a reader to see a $ symbol as having anything to do with DOM related
functions, and very good reasons for them to see the $ symbol as having
something to do with machine generation.
If you're open to the idea of project-specific style-conventions, then
as I've said it's a matter of a few seconds to see the consistent
convention in any application that uses the dollar sign this way. I
propose it because so many web applications are getting so gui heavy,
and it's the shortest, clearest means of distinction that I can see.
c) you can combine it with other useful element functions, like
$make(tagname, id); // make an element
$input(type, name, value, [id]) // make an input
$text(text) // make a text node

Wrapping common code structures into parameterised functions is not an
idea that requires, or justifies, a specific naming convention.
dom_make, dom_input and dom_text being just as possible, and
fractionally less obscure.
You can spot a dollar sign more easily in a sea of roman characters.
d) this approach allows you write applications more quickly.

It is well known that the maintenance costs are always a significant
factor in applications.
Yes, which is why brevity and readability are so important.
e) you can then optimise for speed in any areas that
are script-heavy.

There is no relationship between an ability to optimise for speed and
the use of any particular naming convention.
If you can express the initial prototype more quickly and clearly then
yes, there is.
f) most programmers would know it to be a waste of time to
rewrite something that works for style alone

Most programmers would know enough not to write something obscurely in
the first place.
Your equation of clarity with an absolute naming convention, is close
minded. There is much more to clarity.
g) In this particular case, nobody would be confused for
more than ten seconds, if at all, after which this function
will save them a great many keystrokes, without a noticable
difference in page performance.

If you were not even aware of the IE memory leak problem I don't think
you have ever written anything with javascript that qualifies you to
make such statements about performance.
Lucky for me I don't care what you think I'm qualified to do.
Of all the things that may be 'saved' in software authoring I don't
think anyone would seriously propose that keystrokes are something that
needs worrying about.
Brevity of code is not just keystrokes. You can look at more code at
once and still see more comments and whitespace. The code is closer to
english and no matter how well you get to know any computer language,
english will be clearer, especially when you've been away from the
project for a while or someone else takes over some of it.
The overall impact of having to stuff a document with an
excessive number of unique element IDs may be less apparent,
but it will act to hinder development in the longer term.
So will long and complicated statements, which are inevitable
if you stick as close as possible to the native javascript/dom
methods when writing your applicatoin.


Well? Replacing re-occurring blocks of code with parameterised function
call is normal and sensible. I would question the reason for wrapping
code in a function when that function itself only contains one line of
code.
To save 10 - 20 bytes per call.
Generally, javascript is easier to write, maintain and understand
when it uses references to objects directly instead of indirectly
referring to them with string values representing names and IDs.
True, but to get the initial reference you often have to
use id,

No you don't. In an event driven system like a web browser the starting
point of code execution is usually attached to the DOM elements of
interest, or they can be recovered from the event object (with elements
that have structural relationships to those elements being recoverable
by reference through the DOM), and if you create an element you have a
reference to it at that point and do not need to get another so long as
you don't prematurely throw it away.
Interesting, I'll try to be more efficient with my references.
and if you do this many times in a document, on various
events for example, then you're going to get sick of typing
document.getElementById() for such a common task.

I may if I did. A quick text search for '.getElementById(' in all the
60,000 lines of javascript code in the web application I am working on
at the moment shows 220 occurrences.
Also you could modify $del() to accept either elements(by
reference) or IDs and act accordingly.

Given how simple the contents of the actual function is, and the fact
that the programmer should know whether they re dealing with an ID sting
or an object reference at the point of calling the function, it would
probably be better to have two function than have each function call
test and branch.
Good idea.
Richard.
Aug 7 '06 #10

P: n/a
darwinist wrote:
Richard Cornford wrote:
<snip>
>Confusion results form disappointing expectations. ...

And I still say this is vague theory when I have presented
a practical example, if an imperfect one, to illustrate just
how much "confusion" would ensue before one sees that $del
is delete an element and $make is make an element and all
else in the application is clearer.
You are basing you example on your own expectations, while knowing that
the specification states that Identifiers beginning with $ symbols are
machine generated means the experienced javascript programmer has to ask
themselves how and why these functions are being machine generated and
spend time determining that they in fact are not. You think the
situation is simpler than it is because you already know that they re
not machine generated.
It's a style convention, which are project specific, and
unenforcable by interpreters as you say.
And it takes a fool to introduce a project specific style convention
that contradicts a specification defined convention when numerous
alternative conventions could equally well (or better) achieve the same
function grouping without impacting existing expectations.
>>>>i find it highly intuitive to group functions which
handle dom-related elements, and it works across browsers.

What 'works' is not really an issue.

Sorry I must have misheard you. Could you say that again?

What 'works' is not really an issue. In allowing the inclusion
of the $ symbol in identifiers and then asserting that it
should only be used at the start of a machine generated
Identifier the specification had no choice but allow any
Identifier starting with a $ symbol to be legal. The
interpreter cannot know that an Identifier has been machine
generated, and so cannot apply special tokenising/parsing
rules for machine generated Identifiers. Using them where
they should not be used is going to 'work', it is just
something that should not be done.

If the only practical difference it makes is to how some
people interpret it,
How people interpret code is very important to how effectively and
efficiently they re going to be able to maintain it. And it is not just
'some people' but experienced javascript programmers, the very people
who are likely to be expensively be brought in to fix faults in some web
application.
then it's a style difference, which has no place in a
language specification.
The wisdom of including it (particularly as it appears to just be a
carry-over from a similar constraint in Java) does not change the fact
that it is there and can be expected to be familiar to javascript
programmers (so be their expectation).
Just cause it's in a spec doesn't mean it
should be followed,
Because it is in the spec it can be expected to be familiar to
javascript programmers, and should be followed because not doing so will
contradict the resulting expectation.
when the spec doesn't describe the actual platform
you are writing for.
What?

<snip>
>The act of specifically stating the convention if the
language's specification pretty much guarantees that any
serious javascript programmer will be familiar with it.
From that starting point an formal coding standards document
that overwrites that convention with another would be
ill-conceived.

Not necessarily, it depends what actual difference it makes.
So what difference does using a leading $ symbol to group DOM related
functions make over using any other naming convention for the same
functions make? A leading lowercase - d - would be as short, a leading
underscore as short and as obscure, and a leading - dom_ - pretty short
and approaching self-documenting.
>>It depends on how well any convention is suited to the
task that your code is intended to achieve.

Any naming convention could make DOM related method distinct
from others, and may would be less ambiguous themselves,
and all others would avoid facing the reasonable assumption
that the convention laid down in

Except manipulating dom objects is so common and important
that an obvious single symbol is very efficient.
It is the choice of symbol that is being objected to.
dom_make takes up more space
on the screen without adding clarity.
Nonsense, the character sequence - dom - has inherent meaning to anyone
who is programming web browsers, and a few extra characters to render
code more meaningful is not that much of a cost.
$make is easier to spot, as well.
>>>>You can talk in vague theory ...
<snip>
>>I challenge you to find an obscure
line in this entire windowing system:
http://darwinist.googlepages.com/htmldesktop.html

Don't be silly.

Don't be puritanical.

In any substantial body of code there will be at least
one line that is totally obscure when taken out of context.

But we are not interested in absolute obscurity but rather
relative obscurity. Your:-

$del("something");

- is inherently obscure, It just needs comparing with
alternatives such as:-

removeDomElementById("soemthing);

In the first case you almost know nothing without the source
code for - $del -, while in the second case the odds are
good that the reader does not have to even go an see what
the functions does because its name has already told them.

Besides the fact that the this approach makes the programs
much shorter,
Shorter is not better.
allowing context to be seen more quickly,
In development code the expectation would be that a function call would
appear on a single line so the context would not be significantly harder
to read in either case.
anyone browsing the code ought to have sufficient commentary
as to why something is being deleted, and what it is.
And in the real world code gets modified in debugging and comments get
left as they are, so they can get out of date. Self-documenting code
tells you what it is doing in a way that changes with every code
modification. Comments are not the best approach to obscure code,
clearer code is.
An application must be allowed its own linguistic context
in which things like "del" have a known meaning.
That is of no value at all for newcomers to the code. A newcomer
reading - $del('something'); - is off on a chase to find out what the
meaning is (misdirected by their disappointed expectations), while a
newcomer reading - removeDomElementById("soemthing); - can go straight
on to reading the next line of code.
In a file-system-based command line it would be assumed it
was a file,
Very OS/Shell dependent.
in any web-application that's gui heavy, it might mean
a gui element. The $ just makes it even more clear in
the context of that particular project.
Not if it first make it unclear in the context of javascript.
>><snip>
>>>>I'm not particularly interested in coding to the bugs of a
product whose manufacturers don't even pretend it's good
anymore.
>
$del("id"); is quick and easy and allows you to be more
productive.

What it does for you is not relevant. It will potentially get
in the way of the productivity of a third party knowledgeable
javascript programmer attempting to maintain your code as they
will have to spend effort determining that this apparently
machine generated Identifier is not actually machine generated
(and then expend effort re-writing your code to eliminate the
faulty Identifiers).

a) it's a common practice (ask google if you don't believe me)

What is common practice? Using initial $ symbols in javascript
code, or using initial $ symbols to indicate DOM related methods?

The latter,
"using initial $ symbols to indicate DOM related methods". That is not
common practice. You are in fact the first person who I have encountered
proposing such a convention (and many have proposed alternative used for
leading $ symbols, of which an indicator of string values has been the
most repeated).
to return elements by id or reference.
Was that the latter?
I don't know if many people use $make and $del and $input and
$text,
That sounds personal rather than 'common practice'.
but I liked the idea and the syntax so much (being a
php programmer, which I think a lot of js programmers
are these days), that I extended the idea for my
windowing system.
That sounds personal rather than 'common practice'.
>First, the vast majority of the javascript code in the world was
written (or copy and pasted) by people who did not really know what
they were doing (and most of the stuff that can be copy and pasted
was written by equally under informed individuals). As a result any
appeal to what is 'common practice' is likely an appeal to 'bad
practice'.

Your primary argument against using the $ to denote dom
elements is one of convention,
No, it is one of expectations. There are good reasons to expect
javascript programmers to have a particular expectation and no good
reasons for disappointing it.
to avoid confusing people who are experienced javascript
programmers. What if they're experienced in these bad
practices?
It would not matter, you could not dismiss the possibility that the
leading $ did indicate a machine generated Identifier, and the time
wasted verifying that it was not has then been wasted.

<snip>
If you're open to the idea of project-specific style-conventions,
then as I've said it's a matter of a few seconds to see the
consistent convention in any application that uses the dollar
sign this way.
It would only be a matter of a few seconds if there was someone about to
ask, otherwise reading the documentation would take at leas some minutes
(assuming that someone had documented the convention, and verifying that
the Identifier was not machine generated from the code could be very
time consuming (as if it was machine generated you would eventually
discover where and how but you could not be certain that it never was
until everything had been examined).
I propose it because so many web applications are getting
so gui heavy, and it's the shortest, clearest means of
distinction that I can see.
Short is not necessarily good and clear it is not.
>>c) you can combine it with other useful element functions,
like
$make(tagname, id); // make an element
$input(type, name, value, [id]) // make an input
$text(text) // make a text node

Wrapping common code structures into parameterised functions
is not an idea that requires, or justifies, a specific naming
convention. dom_make, dom_input and dom_text being just as
possible, and fractionally less obscure.

You can spot a dollar sign more easily in a sea of roman
characters.
Why am I looking for the dollar sign in a sea of characters? I am
looking at code structure and the flow of the logic. I don't need to
pick particular method names out quickly, I need to know what a function
call is doing at the point where it is made.
>>d) this approach allows you write applications more quickly.

It is well known that the maintenance costs are always a
significant factor in applications.

Yes, which is why brevity and readability are so important.
But your brevity is at the cost of readability. The natural meaning of
what you have written is other than your interpretation, and what you
have avoided writing for brevity was what could have provided inherent
meaning.
>>e) you can then optimise for speed in any areas that
are script-heavy.

There is no relationship between an ability to optimise for
speed and the use of any particular naming convention.

If you can express the initial prototype more quickly and
clearly then yes, there is.
There is no relationship between an ability to optimise for
speed and the use of any particular naming convention.
>>f) most programmers would know it to be a waste of time
to rewrite something that works for style alone

Most programmers would know enough not to write something
obscurely in the first place.

Your equation of clarity with an absolute naming convention,
I made no such equation. You are the one proposing absolute naming
conventions here. I am proposing names that convey inherent meaning.
is close minded. There is much more to clarity.
>>g) In this particular case, nobody would be confused for
more than ten seconds, if at all, after which this function
will save them a great many keystrokes, without a noticable
difference in page performance.

If you were not even aware of the IE memory leak problem I
don't think you have ever written anything with javascript
that qualifies you to make such statements about performance.

Lucky for me I don't care what you think I'm qualified to do.
You can find out in whichever way your prefer.
>Of all the things that may be 'saved' in software authoring
I don't think anyone would seriously propose that keystrokes
are something that needs worrying about.

Brevity of code is not just keystrokes. You can look at more
code at once and still see more comments and whitespace.
The code is closer to english and no matter how well you get
to know any computer language, english will be clearer,
especially when you've been away from the project for a
while or someone else takes over some of it.
Leading $ symbols are "nearer to English"?
>The overall impact of having to stuff a document with an
excessive number of unique element IDs may be less apparent,
but it will act to hinder development in the longer term.

So will long and complicated statements, which are inevitable
if you stick as close as possible to the native javascript/dom
methods when writing your applicatoin.


Well? Replacing re-occurring blocks of code with parameterised
function call is normal and sensible. I would question the reason
for wrapping code in a function when that function itself only
contains one line of code.

To save 10 - 20 bytes per call.
<snip>

Ten to twenty bytes of what? For each function call the javascript
engine must create its representation of the execution context (to hold
the current scope), create and initialise an - arguments - object and
create and initials a Variable/activation object, that is at least two,
and probably more, structures assembled in memory and later garbage
collected. Twenty bytes here or there are not going to make a great deal
of difference to that.

Richard.
Aug 7 '06 #11

P: n/a
Richard Cornford wrote:
darwinist wrote:
Richard Cornford wrote:
<snip>
Confusion results form disappointing expectations. ...
And I still say this is vague theory when I have presented
a practical example, if an imperfect one, to illustrate just
how much "confusion" would ensue before one sees that $del
is delete an element and $make is make an element and all
else in the application is clearer.

You are basing you example on your own expectations, while knowing that
the specification states that Identifiers beginning with $ symbols are
machine generated means the experienced javascript programmer has to ask
themselves how and why these functions are being machine generated and
spend time determining that they in fact are not. You think the
situation is simpler than it is because you already know that they re
not machine generated.
It's a style convention, which are project specific, and
unenforcable by interpreters as you say.

And it takes a fool to introduce a project specific style convention
that contradicts a specification defined convention when numerous
alternative conventions could equally well (or better) achieve the same
function grouping without impacting existing expectations.
Sure if they achieve it equally well.
>>>i find it highly intuitive to group functions which
handle dom-related elements, and it works across browsers.

What 'works' is not really an issue.

Sorry I must have misheard you. Could you say that again?

What 'works' is not really an issue. In allowing the inclusion
of the $ symbol in identifiers and then asserting that it
should only be used at the start of a machine generated
Identifier the specification had no choice but allow any
Identifier starting with a $ symbol to be legal. The
interpreter cannot know that an Identifier has been machine
generated, and so cannot apply special tokenising/parsing
rules for machine generated Identifiers. Using them where
they should not be used is going to 'work', it is just
something that should not be done.
If the only practical difference it makes is to how some
people interpret it,

How people interpret code is very important to how effectively and
efficiently they re going to be able to maintain it. And it is not just
'some people' but experienced javascript programmers, the very people
who are likely to be expensively be brought in to fix faults in some web
application.
What development system is this where someone can't look up a function
immediately?
then it's a style difference, which has no place in a
language specification.

The wisdom of including it (particularly as it appears to just be a
carry-over from a similar constraint in Java) does not change the fact
that it is there and can be expected to be familiar to javascript
programmers (so be their expectation).
Just cause it's in a spec doesn't mean it
should be followed,

Because it is in the spec it can be expected to be familiar to
javascript programmers, and should be followed because not doing so will
contradict the resulting expectation.
What they expect is one factor. Overall clarity and readability is what
matters and I suggest a single symbol (perhaps you could name a more
appropriate one) make this distinction clear and takes about 10 seconds
to familiarise yourself with.
when the spec doesn't describe the actual platform
you are writing for.

What?
The javascript spec doesn't describe the actual programming platforms
we use, not completelely. We need to write for the interpreters that
people use, not the specs of an interpreter that should exist.
<snip>
The act of specifically stating the convention if the
language's specification pretty much guarantees that any
serious javascript programmer will be familiar with it.
From that starting point an formal coding standards document
that overwrites that convention with another would be
ill-conceived.
Not necessarily, it depends what actual difference it makes.

So what difference does using a leading $ symbol to group DOM related
functions make over using any other naming convention for the same
functions make? A leading lowercase - d - would be as short, a leading
underscore as short and as obscure, and a leading - dom_ - pretty short
and approaching self-documenting.
Underscores could work. I tend to associate them with system calls,
myself.
>It depends on how well any convention is suited to the
task that your code is intended to achieve.

Any naming convention could make DOM related method distinct
from others, and may would be less ambiguous themselves,
and all others would avoid facing the reasonable assumption
that the convention laid down in
Except manipulating dom objects is so common and important
that an obvious single symbol is very efficient.

It is the choice of symbol that is being objected to.
Well ok, but I really think its inclusion in the spec is giving it
undue importance in your mind.
dom_make takes up more space
on the screen without adding clarity.

Nonsense, the character sequence - dom - has inherent meaning to anyone
who is programming web browsers, and a few extra characters to render
code more meaningful is not that much of a cost.
$make is easier to spot, as well.
>>>You can talk in vague theory ...
<snip>
>I challenge you to find an obscure
line in this entire windowing system:
http://darwinist.googlepages.com/htmldesktop.html

Don't be silly.

Don't be puritanical.

In any substantial body of code there will be at least
one line that is totally obscure when taken out of context.

But we are not interested in absolute obscurity but rather
relative obscurity. Your:-

$del("something");

- is inherently obscure, It just needs comparing with
alternatives such as:-

removeDomElementById("soemthing);

In the first case you almost know nothing without the source
code for - $del -, while in the second case the odds are
good that the reader does not have to even go an see what
the functions does because its name has already told them.
Besides the fact that the this approach makes the programs
much shorter,

Shorter is not better.
Not if it's more obscure, but in a properly defined context:
"del(element);"
is fairly clear to any programmer where
"removeDomElementById(element);"
is redundant and less readable.
allowing context to be seen more quickly,

In development code the expectation would be that a function call would
appear on a single line so the context would not be significantly harder
to read in either case.
The longer the function and method calls the more often you have to
either split functions across lines, or calculate parameters separately
before passing them. All this means less gets said per screen.
anyone browsing the code ought to have sufficient commentary
as to why something is being deleted, and what it is.

And in the real world code gets modified in debugging and comments get
left as they are, so they can get out of date. Self-documenting code
tells you what it is doing in a way that changes with every code
modification. Comments are not the best approach to obscure code,
clearer code is.
Both are necessary. Trying to include too much documentation in the
code itself actually makes it less readable for things like skimming
functions and scanning for particular lines. I agree that obscure code
cannot be solved by comments, but if a function's purpose is relatively
clear then the purpose of a line in it which reads "del(element)" or
"del(list)" or even "del(x)" will be clear.
An application must be allowed its own linguistic context
in which things like "del" have a known meaning.

That is of no value at all for newcomers to the code. A newcomer
reading - $del('something'); - is off on a chase to find out what the
meaning is (misdirected by their disappointed expectations), while a
newcomer reading - removeDomElementById("soemthing); - can go straight
on to reading the next line of code.
But the chase takes a few seconds, while the more verbose function call
will take up a bit more space and time every time it's used, and has a
lot of words together with no spaces or other punctuation in between.
In a file-system-based command line it would be assumed it
was a file,

Very OS/Shell dependent.
in any web-application that's gui heavy, it might mean
a gui element. The $ just makes it even more clear in
the context of that particular project.

Not if it first make it unclear in the context of javascript.
Clear is a short function with descriptive comments. Clear is not a
style-convention specific to that partiuclar language.
><snip>
I'm not particularly interested in coding to the bugs of a
product whose manufacturers don't even pretend it's good
anymore.

$del("id"); is quick and easy and allows you to be more
productive.

What it does for you is not relevant. It will potentially get
in the way of the productivity of a third party knowledgeable
javascript programmer attempting to maintain your code as they
will have to spend effort determining that this apparently
machine generated Identifier is not actually machine generated
(and then expend effort re-writing your code to eliminate the
faulty Identifiers).

a) it's a common practice (ask google if you don't believe me)

What is common practice? Using initial $ symbols in javascript
code, or using initial $ symbols to indicate DOM related methods?
The latter,

"using initial $ symbols to indicate DOM related methods". That is not
common practice. You are in fact the first person who I have encountered
proposing such a convention (and many have proposed alternative used for
leading $ symbols, of which an indicator of string values has been the
most repeated).
to return elements by id or reference.

Was that the latter?
In a narrow sense.
I don't know if many people use $make and $del and $input and
$text,

That sounds personal rather than 'common practice'.
but I liked the idea and the syntax so much (being a
php programmer, which I think a lot of js programmers
are these days), that I extended the idea for my
windowing system.

That sounds personal rather than 'common practice'.
I adopted the basic dollar function idea for getting elements and
extended it.
First, the vast majority of the javascript code in the world was
written (or copy and pasted) by people who did not really know what
they were doing (and most of the stuff that can be copy and pasted
was written by equally under informed individuals). As a result any
appeal to what is 'common practice' is likely an appeal to 'bad
practice'.
Your primary argument against using the $ to denote dom
elements is one of convention,

No, it is one of expectations. There are good reasons to expect
javascript programmers to have a particular expectation and no good
reasons for disappointing it.
to avoid confusing people who are experienced javascript
programmers. What if they're experienced in these bad
practices?

It would not matter, you could not dismiss the possibility that the
leading $ did indicate a machine generated Identifier, and the time
wasted verifying that it was not has then been wasted.
You couldn't dismiss that possibility no matter what the variable was
called, since you say most javascript is written by one group of poorly
informed individuals and cut-and-pasted by another.
<snip>
If you're open to the idea of project-specific style-conventions,
then as I've said it's a matter of a few seconds to see the
consistent convention in any application that uses the dollar
sign this way.

It would only be a matter of a few seconds if there was someone about to
ask, otherwise reading the documentation would take at leas some minutes
(assuming that someone had documented the convention, and verifying that
the Identifier was not machine generated from the code could be very
time consuming (as if it was machine generated you would eventually
discover where and how but you could not be certain that it never was
until everything had been examined).
Geez: search-"function $del("-"all files in project"->"find";
I propose it because so many web applications are getting
so gui heavy, and it's the shortest, clearest means of
distinction that I can see.

Short is not necessarily good and clear it is not.
>c) you can combine it with other useful element functions,
like
$make(tagname, id); // make an element
$input(type, name, value, [id]) // make an input
$text(text) // make a text node

Wrapping common code structures into parameterised functions
is not an idea that requires, or justifies, a specific naming
convention. dom_make, dom_input and dom_text being just as
possible, and fractionally less obscure.
You can spot a dollar sign more easily in a sea of roman
characters.

Why am I looking for the dollar sign in a sea of characters? I am
looking at code structure and the flow of the logic. I don't need to
pick particular method names out quickly, I need to know what a function
call is doing at the point where it is made.
It behaves like punctuation, and punctuation tells you about structure.
Interacting with the gui deserves a kind of punctuation, or at least
can benefit from one.
>d) this approach allows you write applications more quickly.

It is well known that the maintenance costs are always a
significant factor in applications.
Yes, which is why brevity and readability are so important.

But your brevity is at the cost of readability. The natural meaning of
what you have written is other than your interpretation, and what you
have avoided writing for brevity was what could have provided inherent
meaning.
Functions should not try to fit the language they are written in, but
rather the application they are creating. That is their "natural"
meaning.
>e) you can then optimise for speed in any areas that
are script-heavy.

There is no relationship between an ability to optimise for
speed and the use of any particular naming convention.
If you can express the initial prototype more quickly and
clearly then yes, there is.

There is no relationship between an ability to optimise for
speed and the use of any particular naming convention.
I gave a counter-argument, you just repeated yourself.
>f) most programmers would know it to be a waste of time
to rewrite something that works for style alone

Most programmers would know enough not to write something
obscurely in the first place.
Your equation of clarity with an absolute naming convention,

I made no such equation. You are the one proposing absolute naming
conventions here. I am proposing names that convey inherent meaning.
That can only be taken so far, before you are repeating yourself
unnecessarily to anyone who has spent more than ten minutes with your
code.

Of course function names should have inherent meaning. What kind, how
much, and in what context should that meaning be "inherent"? That is
the point of contention.
is close minded. There is much more to clarity.
>g) In this particular case, nobody would be confused for
more than ten seconds, if at all, after which this function
will save them a great many keystrokes, without a noticable
difference in page performance.

If you were not even aware of the IE memory leak problem I
don't think you have ever written anything with javascript
that qualifies you to make such statements about performance.
Lucky for me I don't care what you think I'm qualified to do.

You can find out in whichever way your prefer.
Thanks
Of all the things that may be 'saved' in software authoring
I don't think anyone would seriously propose that keystrokes
are something that needs worrying about.
Brevity of code is not just keystrokes. You can look at more
code at once and still see more comments and whitespace.
The code is closer to english and no matter how well you get
to know any computer language, english will be clearer,
especially when you've been away from the project for a
while or someone else takes over some of it.

Leading $ symbols are "nearer to English"?
No but single words with punctuation between are clearer than
javascript method calls.
The overall impact of having to stuff a document with an
excessive number of unique element IDs may be less apparent,
but it will act to hinder development in the longer term.

So will long and complicated statements, which are inevitable
if you stick as close as possible to the native javascript/dom
methods when writing your applicatoin.
Well? Replacing re-occurring blocks of code with parameterised
function call is normal and sensible. I would question the reason
for wrapping code in a function when that function itself only
contains one line of code.
To save 10 - 20 bytes per call.
<snip>

Ten to twenty bytes of what? For each function call the javascript
engine must create its representation of the execution context (to hold
the current scope), create and initialise an - arguments - object and
create and initials a Variable/activation object, that is at least two,
and probably more, structures assembled in memory and later garbage
collected. Twenty bytes here or there are not going to make a great deal
of difference to that.
Many javascript applications are installed across the world over
networks and updated often. Downloadability is part of a web-pages
usability.

The main purpose of my desktop was to show how easily and concisely
this functionality can be achieved. Any customised content or style
would need to be on top of this and so it's even more important to keep
down the size of the code.
Richard.
Aug 7 '06 #12

P: n/a
darwinist wrote:
Your primary argument against using the $ to denote dom elements is one
of convention, to avoid confusing people who are experienced
javascript programmers. What if they're experienced in these bad
practices?
What an odd thing to imply, "I will keep programming badly because I'm
used to it."

When I started writing serious javascript I remember lurking in the
various threads of Richard Cornford, Michael Winter et al where they
talked about standards, conventions, and various good practices. At the
time I smirked at their "tame" approach.

Now, having suffered countless times, I find myself nodding knowingly at
wisdom in their words.

Sure, reject whatever you want to but know what why.

Andrew Poulos
Aug 7 '06 #13

P: n/a

darwinist wrote:
Richard Cornford wrote:
darwinist wrote:
Richard Cornford wrote:
You can't win an arguement with the largest troll of this group. He
seems to have infinite time to respond to and confuse everything
someone writes in tons of words. It is best just to not respond to him
or put him on your kill file. He is a rather amateur troll as trolls
goes. He often is quite rude, but usually not nasty. For instance, one
of the most extreme trolls around goes by the handle of
a...@comments.header, among many others. He brags about going through 2
or more remailers. He has over 74000 posts under one name alone. He
often hits hobby groups with the most dirty posts you can imagine. He
often spoofs the name of group members. Such is Usenet. Such is a
reason why many major isps do not provide the Usenet service that they
once did - they are tired of all of the complaints resulting because
Usenet will not police itself, and they are tired of all of the spam
that Usenet posts generate. Some enjoy Usenet fights, rudeness, foul
language, etc. However more and more people are using BBs where the
posts are kept civil and trouble makers can be banned.

Aug 7 '06 #14

P: n/a
Andrew Poulos wrote:
darwinist wrote:
Your primary argument against using the $ to denote dom elements is one
of convention, to avoid confusing people who are experienced
javascript programmers. What if they're experienced in these bad
practices?

What an odd thing to imply, "I will keep programming badly because I'm
used to it."
If they're only bad in the sense that they're unexpected or contrary to
expectation, then the more people that expect them the better they are.
When I started writing serious javascript I remember lurking in the
various threads of Richard Cornford, Michael Winter et al where they
talked about standards, conventions, and various good practices. At the
time I smirked at their "tame" approach.

Now, having suffered countless times, I find myself nodding knowingly at
wisdom in their words.

Sure, reject whatever you want to but know what why.
Sage advice.
Andrew Poulos
Aug 7 '06 #15

P: n/a
justme33 wrote:
darwinist wrote:
Richard Cornford wrote:
darwinist wrote:
Richard Cornford wrote:

You can't win an arguement with the largest troll of this group. He
seems to have infinite time to respond to and confuse everything
someone writes in tons of words. It is best just to not respond to him
or put him on your kill file. He is a rather amateur troll as trolls
goes. He often is quite rude, but usually not nasty. For instance, one
of the most extreme trolls around goes by the handle of
a...@comments.header, among many others. He brags about going through 2
or more remailers. He has over 74000 posts under one name alone. He
often hits hobby groups with the most dirty posts you can imagine. He
often spoofs the name of group members. Such is Usenet. Such is a
reason why many major isps do not provide the Usenet service that they
once did - they are tired of all of the complaints resulting because
Usenet will not police itself, and they are tired of all of the spam
that Usenet posts generate. Some enjoy Usenet fights, rudeness, foul
language, etc. However more and more people are using BBs where the
posts are kept civil and trouble makers can be banned.
I don't think he's a troll. Anyway, I like the freedom of usenet. BBs
are fine, too. They're not mutually exclusive.

Aug 7 '06 #16

P: n/a
On 07/08/2006 06:03, darwinist wrote:
justme33 wrote:
[snipped pointless attributions]
>You can't win an arguement with the largest troll of this group.
There are no regular trolls in this group. There is a village idiot, though.
>He seems to have infinite time to respond to
One of the nice things about Usenet is that it is not a real-time medium
(though I know that can be frustrating for those asking a question). As
such, one can take one's time to compose a response.
>and confuse everything someone writes in tons of words.
Aside from the frequent and unfortunate transposition typos (a
consequence of typing quickly, I suppose), Richard's responses are
rather eloquent.
>It is best just to not respond to him or put him on your kill file.
If one would wish to ignore a reliable source of information, I suppose
one could do that.
>He is a rather amateur troll as trolls goes.
That would seem to be a self-description.
>He often is quite rude, but usually not nasty.
He is to-the-point, as are others, and as am I. We are all adults here,
yes? Usenet is certainly not the place for children. Surely there's no
need for hand-holding?
>For instance, one of the most extreme trolls around goes by the
handle of a...@comments.header, among many others. He brags about
going through 2 or more remailers. He has over 74000 posts under
one name alone. He often hits hobby groups with the most dirty
posts you can imagine. He often spoofs the name of group members.
"...one of the most extreme trolls around..."? So what does any of that
have to do with Richard?
>Such is Usenet.
Any large group of people will contain morons and ne'er-do-wells. Such
is the human race.

[snip]
>However more and more people are using BBs where the posts are kept
civil and trouble makers can be banned.
I should think that more and more people are using Web-based forums
because more and more people are using the Web without knowledge that
Usenet exists.
I don't think he's a troll.
Good; he isn't. Richard is an important contributor to this group. The
same thing can't be said for whoever this on**********@netscape.net
person is, though.

[snip]

Mike
Aug 7 '06 #17

P: n/a

Michael Winter wrote:
On 07/08/2006 06:03, darwinist wrote:
justme33 wrote:

[snipped pointless attributions]
You can't win an arguement with the largest troll of this group.

There are no regular trolls in this group. There is a village idiot, though.
Perhaps there are no regular trolls from your viewpoint, although I
would nearly put you on the troll list from the tone of some of your
posts. The point is that kind and helpful posts cost no more than
shrill and rude ones. It has been my observation that most of the
really top people in scientific and engineering areas do not resort to
such and do not have time to discuss minute trivia.Want-to-bes
sometimes try to impress with their "superior knowledge". I recall a
scientist years ago where I worked who was always trying to impress
everyone with his "superior" knowledge and kept everything in an uproar
by unfounded objections to what others were doing or saying that
usually were of trivial importance. He caused so much disruption that
he was given the choice of taking a course in human relations or
leaving. Unfortunately some use Usenet for the same purpose as the
person I mentioned, or as a substitute for a fight with the wife or
kicking the dog, which will get them into real trouble. And there
usually is no easy way to stop this.

Aug 7 '06 #18

P: n/a
justme33 wrote:
Michael Winter wrote:
>On 07/08/2006 06:03, darwinist wrote:
>>justme33 wrote:
[snipped pointless attributions]
>>>You can't win an argument with the largest troll of this group.
There are no regular trolls in this group. There is a village idiot, though.

Perhaps there are no regular trolls from your viewpoint, although I
would nearly put you on the troll list from the tone of some of your
posts. The point is that kind and helpful posts cost no more than
shrill and rude ones. It has been my observation that most of the
Why is it that you want/hope for free expert advice and then expect it
on your terms? Don't you realise that answers to questions, even if the
tone/attitude is not what you prefer, are the result of someone
volunteering their time, knowledge and effort for your benefit. Pay them
and then you can ask for it on your terms.
really top people in scientific and engineering areas do not resort to
such and do not have time to discuss minute trivia.Want-to-bes
sometimes try to impress with their "superior knowledge". I recall a
scientist years ago where I worked who was always trying to impress
everyone with his "superior" knowledge and kept everything in an uproar
by unfounded objections to what others were doing or saying that
usually were of trivial importance. He caused so much disruption that
he was given the choice of taking a course in human relations or
leaving. Unfortunately some use Usenet for the same purpose as the
person I mentioned, or as a substitute for a fight with the wife or
kicking the dog, which will get them into real trouble. And there
usually is no easy way to stop this.
Usenet and companies/institutions, that can't manage their employees,
are not the same thing. If you are unhappy with posts on Usenet don't
read them.

Andrew Poulos
Aug 8 '06 #19

P: n/a
justme33 wrote:
You can't win an arguement with the largest troll of
this group.
<snip>
... confuse everything someone writes in tons of words.
Confused by words? Does that mean you resolve your script design debates
with fisticuffs?
... . He is a rather amateur troll as trolls goes.
That would be "as trolls go".

<snip>
... . For instance, one of the most extreme trolls around ...
... brags about going through 2 or more remailers.
<snip>

Are you implying that there is a relationship between non-amateur
trolling and attempted anonymity - justme33?

Richard.
Aug 10 '06 #20

P: n/a
darwinist wrote:
Richard Cornford wrote:
<snip>
>You are basing you example on your own expectations, ...
<snip>
>>It's a style convention, which are project specific,
and unenforcable by interpreters as you say.
>And it takes a fool to introduce a project specific
style convention that contradicts a specification defined
convention when numerous alternative conventions could
equally well (or better) achieve the same function grouping
without impacting existing expectations.

Sure if they achieve it equally well.
But they can achieve it equally well .You introduced and imposed your
interpretation of the dollar symbol, there is no other possible source
of meaning for the symbol in your context (beyond something referring to
specific types of currency, or machine generated Identifiers). If you
can arbitrarily attach your own meaning to any one symbol you could
attach that meaning to any other ('symbol' here being more than just a
single character, as there are not that many of them available, but
anything (implying character sequence) that could be symbolic of the
function grouping used).

<snip>
>>If the only practical difference it makes is to how some
people interpret it,

How people interpret code is very important to how effectively
and efficiently they re going to be able to maintain it.
Inevitably, so advantages follow from the code satisfying the
(preferably more established) expectations of the reader.
>And it is not just 'some people' but experienced javascript
programmers, the very people who are likely to be expensively
be brought in to fix faults in some web application.

What development system is this where someone can't look up a
function immediately?
Finding a function definition in a source code files does not say
anything about how that file is created, and an indicator of a machine
generated Identifier implies a fully or partly machine generated file
and so the need to appreciate the how, where and why of its creation.

<snip>
>Because it is in the spec it can be expected to be familiar
to javascript programmers, and should be followed because
not doing so will contradict the resulting expectation.

What they expect is one factor.
Quite an important factor.
Overall clarity and readability is what matters
It is what matters. Does disappointing a reasonable expectation, while
not providing any relevant implicit meaning (the implicit meaning of $
being currency related) in the Identifier, really contribute to clarity
or readability?
and I suggest a single symbol (perhaps you could name
a more appropriate one)
I would prefer a character sequnce (More sometimes is more).
make this distinction clear and takes about 10
seconds to familiarise yourself with.
I have already disputed your "10 seconds". I still think that you are
seeing this only from the perspective of someone intimately familiar
with the naming convention you have chosen to use. It is inevitable that
you would find it easy to see things from that perspective, but you
should also be able to see that there are advantages in being able to se
things from other perspectives (particularly if working in GUI design).
If you assumed no knowledge of any specific meaning to the $ symbol
where you use it and re-examined the situation it should be fairly
obvious that your source code gains no clarity through its use, and if
you assumed an (any) alternative meaning that the code actually becomes
misleading.

Lets consider the inherent meaning of $, as indicative of a particular
type of currency and examine your functions- $( ... ), $del(id) and
$make( ... ). Intuition might suggest something related to accounting
and/or currency formatting. The reaming parts of the Identifiers, the
'del' and 'make', certainly do not preclude a fiscally related
interpretation.
>>when the spec doesn't describe the actual platform
you are writing for.

What?

The javascript spec doesn't describe the actual
programming platforms we use, not completelely.
The deviations between ECMA 262 and ECMAScript implementations (such as
JavaScript(tm) and JScript) are minimal and largely of no practical
significance. And over time the number of implementation bugs has
diminished, with changes being towards conformance with the
specification.
We need to write for the interpreters that people use,
not the specs of an interpreter that should exist.
You are proposing a practical impossibility. You have no way of
determining what interpreters people actually use, and are not in a
position to gather enough information about all of them anyway.

It is much more practical to write javascript to ECMA 262 and avoid the
few areas where problems are known to exist than to attempt to
accumulate a specific knowledge of the behaviour of all implementations
into a useable sub-set (and even if the latter was realistic the
outcome would likely be the same anyway).
>><snip>
So what difference does using a leading $ symbol to group
DOM related functions make over using any other naming
convention for the same functions make? A leading lowercase
- d - would be as short, a leading underscore as short and
as obscure, and a leading - dom_ - pretty short and
approaching self-documenting.

Underscores could work. I tend to associate them with system
calls, myself.
The most common use of leading underscores is to indicate object
properties that are 'private' by naming convention, and so that would be
expectation best anticipated in others.

<snip>
>It is the choice of symbol that is being objected to.

Well ok, but I really think its inclusion in the spec is
giving it undue importance in your mind.
The effect of its inclusion in the spec is to make it likely to be
familiar to people who know javascript well. The likelihood of
familiarity is what results in the expectation of an expectation, and it
is not acting to disappoint that expectation that I consider
important/significant in the choice of conventions to apply to code
authoring style.

<snip>
>>Besides the fact that the this approach makes the
programs much shorter,

Shorter is not better.

Not if it's more obscure, but in a properly defined context:
"del(element);"
is fairly clear to any programmer where
"removeDomElementById(element);"
is redundant and less readable.
Without the caveat "a properly defined context" that statement would be
very questionable. For a start - element - would be a poor choice of
Identifier for a value that was a string representing an ID, and -
del(elementId); - is not unambiguously acting upon the element referred
to by the ID string.
>>allowing context to be seen more quickly,

In development code the expectation would be that a
function call would appear on a single line so the
context would not be significantly harder to read in
either case.

The longer the function and method calls the more often you
have to either split functions across lines,
Properly indented, I don't have a problem with splitting a function call
across lines. My comment was intended to suggest that a function call
would not often be mixed with other code on the same line (or in the
same expression) and so that there was little need for function names to
be too visually distinct in the source code.
or calculate parameters separately before passing them.
All this means less gets said per screen.
<snip>
>>>>a) it's a common practice (ask google if you don't believe me)

What is common practice? ...
<snip>
>>but I liked the idea and the syntax so much (being a
php programmer, which I think a lot of js programmers
are these days), that I extended the idea for my
windowing system.

That sounds personal rather than 'common practice'.

I adopted the basic dollar function idea for getting
elements and extended it.
That sounds personal rather than 'common practice'.

<snip>
>...., you could not dismiss the possibility that the
leading $ did indicate a machine generated Identifier,
and the time wasted verifying that it was not has then
been wasted.

You couldn't dismiss that possibility no matter what the
variable was called,
Without the leading $ symbol there would be no reason for introducing
the possibility that the Identifier was machine generated.
since you say most javascript is written by one group of
poorly informed individuals and cut-and-pasted by another.
It would also be an action against the inherent understandability of
javascript source code to include a machine generated Identifier that
did not commence with a $ symbol.
><snip>
>>If you're open to the idea of project-specific
style-conventions, then as I've said it's a matter of
a few seconds to see the consistent convention in any
application that uses the dollar sign this way.

It would only be a matter of a few seconds if there was
someone about to ask, otherwise reading the documentation
would take at leas some minutes (assuming that someone had
documented the convention, and verifying that the Identifier
was not machine generated from the code could be very time
consuming (as if it was machine generated you would eventually
discover where and how but you could not be certain that it
never was until everything had been examined).

Geez: search-"function $del("-"all files in project"->"find";
Now show me the search term for the back-end that, when it is not found,
verifies that the Identifier/function definition is _not_ machine
generated? Say the back-end is (100%) Java, what do you search for? What
if it is N tier written in a number of languages?

<snip>
>>You can spot a dollar sign more easily in a sea of
roman characters.

Why am I looking for the dollar sign in a sea of
characters? I am looking at code structure and the flow
of the logic. I don't need to pick particular method names
out quickly, I need to know what a function call is doing
at the point where it is made.

It behaves like punctuation, and punctuation tells you
about structure. Interacting with the gui deserves a kind
of punctuation, or at least can benefit from one.
That is only going to work if _every_ interaction with the DOM is
similarly wrapped in a function call, even something as simple as
reading a value from a form element once. Apart from the performance hit
of doing that, you would start to get to the point where the whole set
of functions beginning with $ symbols was so large that they needed
distinguishing names anyway.
>>>>d) this approach allows you write applications more quickly.

It is well known that the maintenance costs are always
a significant factor in applications.

Yes, which is why brevity and readability are so important.

But your brevity is at the cost of readability. The natural
meaning of what you have written is other than your
interpretation, and what you have avoided writing for brevity
was what could have provided inherent meaning.

Functions should not try to fit the language they are written
in,
Which has no relationship to giving functions names that say something
about what they do.
but rather the application they are creating. That is
their "natural" meaning.
That sounds impressive, but doesn't appear to mean anything (that is, it
sounds like marketing-speak).

Function names should say enough to state what the function is doing at
the point where the function is called, and without reference to the
actual function definition.
>>>>e) you can then optimise for speed in any areas that
are script-heavy.

There is no relationship between an ability to optimise
for speed and the use of any particular naming convention.

If you can express the initial prototype more quickly and
clearly then yes, there is.

There is no relationship between an ability to optimise for
speed and the use of any particular naming convention.

I gave a counter-argument, you just repeated yourself.
I did not see a counter argument, only an assertion of a relationship
along the lines of; "If you can express the initial prototype more
quickly" then ' there _is_ a relationship between an ability to optimise
for speed and the use of any particular naming convention'. Where the
latter does not follow from the former unless there was demonstration
that a "particular naming convention" (rather than naming conventions in
general) directly resulted in an ability to "express the initial
prototype more quickly" (whatever that is intended to mean).

You have not demonstrated that any "particular naming convention" (or
that your particular naming convention) has any benefits (presumably
resulting in the quicker expression of prototypes) that cannot be found
in other naming conventions.
<snip>
>>Your equation of clarity with an absolute naming
convention,

I made no such equation. You are the one proposing absolute
naming conventions here. I am proposing names that convey
inherent meaning.

That can only be taken so far, before you are repeating
yourself unnecessarily to anyone who has spent more than
ten minutes with your code.
A call to the same function is a call to the same function whatever the
name of that function is.
Of course function names should have inherent meaning. What
kind, how much,
Sufficient that it becomes unnecessary to cross-reference the function
call with the function definition, certainly whenever the function
definition is expected to be some distance form the call.
and in what context should that meaning be "inherent"?
If a context is beyond 'an understanding of the native language of the
programmer' (or at least the language that (s)he used when writing the
Identifiers, as that sometimes is not their native language) then the
meaning is not 'inherent'.
That is the point of contention.
Conventions provide meaning beyond what is inherent. For a programmer
common, well known/recognised conventions may provide meaning that is
approaching 'inherent' in its significance; and expectation that
something will mean something specific.

<snip>
>>The code is closer to english and no matter how well you
get to know any computer language, english will be clearer,
especially when you've been away from the project for a
while or someone else takes over some of it.

Leading $ symbols are "nearer to English"?

No but single words with punctuation between are clearer than
javascript method calls.
The choice between camel-case and using underscores to separate words in
Identifiers either arbitrary or the subject of convention (possibly
formalised). I am told that when reading most of the time it is the
recognition of patterns in the symbols on a page that allows
understanding, rather than the parsing of sequences of letters. In that
way a camel-case Identifier can be seen as the same on each occasion it
is referenced and its meaning only derived from the sequence of
characters it contains on the first reference.

If camel-case really were an issue we would already be habitually using
underscores to separate words in Identifiers.

<snip>
>>>>So will long and complicated statements, which are
inevitable if you stick as close as possible to the
native javascript/dom methods when writing your applicatoin.
Well? Replacing re-occurring blocks of code with parameterised
function call is normal and sensible. I would question the
reason for wrapping code in a function when that function itself
only contains one line of code.

To save 10 - 20 bytes per call.
<snip>

Ten to twenty bytes of what? For each function call the
javascript engine must create its representation of the
execution context (to hold the current scope), create and
initialise ... .

Many javascript applications are installed across the world
over networks and updated often. Downloadability is part of
a web-pages usability.
But given that HTTP 1.1 requires user agents and servers to support zip
compression/decompression downloadability is (or could/should be)
related to the post-compression nature of the source, and repetition is
what compresses best. The practical impact of may occurrences of the
same 10-20 characters of source text is likely to be negligible.
The main purpose of my desktop was to show how easily and
concisely this functionality can be achieved. Any customised
content or style would need to be on top of this and so it's
even more important to keep down the size of the code.
Or; the implied necessity to integrate the existing code with the
javascript code needed for any real application makes it particularly
important to maximise the readability of the code, especially for the
experienced javascript programmers who are the only people who should
sensibly be employed in writing a web application sufficiently complex
as to require an in-browser windowing GUI.

Richard.
Aug 10 '06 #21

P: n/a
Richard Cornford wrote:
[...]
It would only be a matter of a few seconds if there was
someone about to ask, otherwise reading the documentation
would take at leas some minutes (assuming that someone had
documented the convention, and verifying that the Identifier
was not machine generated from the code could be very time
consuming (as if it was machine generated you would eventually
discover where and how but you could not be certain that it
never was until everything had been examined).
Geez: search-"function $del("-"all files in project"->"find";

Now show me the search term for the back-end that, when it is not found,
verifies that the Identifier/function definition is _not_ machine
generated? Say the back-end is (100%) Java, what do you search for? What
if it is N tier written in a number of languages?
You're right it would only work in a particular context, that of a
single, self-contained, client-engine script, that was not altered by
any automatic process. Perhaps I don't have enough experience to know
why you would want to use javascript outside of such a domain. For
other features there are better languages, as far as I know. Perhaps
you could enlighten me.
<snip>
[...]
Functions should not try to fit the language they are written
in,

Which has no relationship to giving functions names that say something
about what they do.
but rather the application they are creating. That is
their "natural" meaning.

That sounds impressive, but doesn't appear to mean anything (that is, it
sounds like marketing-speak).
The purpose and function of an application defines a context that you
can see even before the actual code is written. Short and common words
will therefore have a more specific meaning in the application, than in
just any program written in the same language.
Function names should say enough to state what the function is doing at
the point where the function is called, and without reference to the
actual function definition.
>>>e) you can then optimise for speed in any areas that
are script-heavy.

There is no relationship between an ability to optimise
for speed and the use of any particular naming convention.

If you can express the initial prototype more quickly and
clearly then yes, there is.

There is no relationship between an ability to optimise for
speed and the use of any particular naming convention.
I gave a counter-argument, you just repeated yourself.

I did not see a counter argument, only an assertion of a relationship
along the lines of; "If you can express the initial prototype more
quickly" then ' there _is_ a relationship between an ability to optimise
for speed and the use of any particular naming convention'. Where the
latter does not follow from the former unless there was demonstration
that a "particular naming convention" (rather than naming conventions in
general) directly resulted in an ability to "express the initial
prototype more quickly" (whatever that is intended to mean).
Well an application, for the writer, is a series of statements. The
first proofs of concept for all the features is a prototype, and if
your naming convention is economical, you can express (the statements
of) those proofs more quickly and in less space.
You have not demonstrated that any "particular naming convention" (or
that your particular naming convention) has any benefits (presumably
resulting in the quicker expression of prototypes) that cannot be found
in other naming conventions.
<snip>
>Your equation of clarity with an absolute naming
convention,

I made no such equation. You are the one proposing absolute
naming conventions here. I am proposing names that convey
inherent meaning.
That can only be taken so far, before you are repeating
yourself unnecessarily to anyone who has spent more than
ten minutes with your code.

A call to the same function is a call to the same function whatever the
name of that function is.
Of course function names should have inherent meaning. What
kind, how much,

Sufficient that it becomes unnecessary to cross-reference the function
call with the function definition, certainly whenever the function
definition is expected to be some distance form the call.
and in what context should that meaning be "inherent"?

If a context is beyond 'an understanding of the native language of the
programmer' (or at least the language that (s)he used when writing the
Identifiers, as that sometimes is not their native language) then the
meaning is not 'inherent'.
That is the point of contention.

Conventions provide meaning beyond what is inherent. For a programmer
common, well known/recognised conventions may provide meaning that is
approaching 'inherent' in its significance; and expectation that
something will mean something specific.

<snip>
>The code is closer to english and no matter how well you
get to know any computer language, english will be clearer,
especially when you've been away from the project for a
while or someone else takes over some of it.

Leading $ symbols are "nearer to English"?
No but single words with punctuation between are clearer than
javascript method calls.

The choice between camel-case and using underscores to separate words in
Identifiers either arbitrary or the subject of convention (possibly
formalised). I am told that when reading most of the time it is the
recognition of patterns in the symbols on a page that allows
understanding, rather than the parsing of sequences of letters. In that
way a camel-case Identifier can be seen as the same on each occasion it
is referenced and its meaning only derived from the sequence of
characters it contains on the first reference.

If camel-case really were an issue we would already be habitually using
underscores to separate words in Identifiers.
That's not my issue, my issue is how much each "word" is doing.
Javascript method calls are a single action, but often three or four
words mashed together. Using the context of a specific function or
application, that action could be given a simpler, more readable label.
<snip>
>>>So will long and complicated statements, which are
inevitable if you stick as close as possible to the
native javascript/dom methods when writing your applicatoin.
Well? Replacing re-occurring blocks of code with parameterised
function call is normal and sensible. I would question the
reason for wrapping code in a function when that function itself
only contains one line of code.

To save 10 - 20 bytes per call.
<snip>

Ten to twenty bytes of what? For each function call the
javascript engine must create its representation of the
execution context (to hold the current scope), create and
initialise ... .
Many javascript applications are installed across the world
over networks and updated often. Downloadability is part of
a web-pages usability.

But given that HTTP 1.1 requires user agents and servers to support zip
compression/decompression downloadability is (or could/should be)
related to the post-compression nature of the source, and repetition is
what compresses best. The practical impact of may occurrences of the
same 10-20 characters of source text is likely to be negligible.
Good point, it's only for literary economy then. For readers and
writers.
The main purpose of my desktop was to show how easily and
concisely this functionality can be achieved. Any customised
content or style would need to be on top of this and so it's
even more important to keep down the size of the code.

Or; the implied necessity to integrate the existing code with the
javascript code needed for any real application makes it particularly
important to maximise the readability of the code, especially for the
experienced javascript programmers who are the only people who should
sensibly be employed in writing a web application sufficiently complex
as to require an in-browser windowing GUI.
Most simple web applications, such as email and message board programs
could benefit from a basic windowing system, it's doesn't require
anything heavy or complicated, which was the point of my example
application.
Richard.
Aug 12 '06 #22

P: n/a
darwinist wrote:
Richard Cornford wrote:
<snip>
>>Geez: search-"function $del("->
"all files in project"->"find";

Now show me the search term for the back-end ...
<snip>
You're right it would only work in a particular context,
that of a single, self-contained, client-engine script,
that was not altered by any automatic process.
Which still required verifying that there is no back-end or
pre-processing involved.
Perhaps I don't have enough experience to know
why you would want to use javascript outside of
such a domain.
The vast majority of web applications are a combinations of server-side
and client-side code, and even pure client-side (HTML + javascript)
projects may be created with a content management system or
pre-processor. So in practice there is usually plenty of potential for
any given piece of javascript to be machine generated by other software.
For other features there are better languages, as far
as I know. Perhaps you could enlighten me.
Not unless you can explain what you are talking about more clearly.

<snip>
>>Functions should not try to fit the language they are
written in,

Which has no relationship to giving functions names that
say something about what they do.
>>but rather the application they are creating. That is
their "natural" meaning.

That sounds impressive, but doesn't appear to mean
anything (that is, it sounds like marketing-speak).

The purpose and function of an application defines a context
that you can see even before the actual code is written.
OK.
Short and common words will therefore have a more
specific meaning in the application, than
in just any program written in the same language.
That would probably depend on the size and scope of the application.
Your 'make', for example, can only have specific meaning in an
application where only one thing (or one type of thing) can be made.
Once there are numerous things that can be made (or deleted) 'make' (or
'del') would need to be qualified by what it was that was being made (or
deleted).

<snip>
>>>>>>e) you can then optimise for speed in any areas
>>that are script-heavy.
>>
>There is no relationship between an ability to optimise
>for speed and the use of any particular naming convention.
>
If you can express the initial prototype more quickly and
clearly then yes, there is.

There is no relationship between an ability to optimise
for speed and the use of any particular naming convention.

I gave a counter-argument, you just repeated yourself.

I did not see a counter argument, only an assertion of a
relationship along the lines of; "If you can express the
initial prototype more quickly" then ' there _is_ a
relationship between an ability to optimise for speed and
the use of any particular naming convention'. Where the
latter does not follow from the former unless there was
demonstration that a "particular naming convention" (rather
than naming conventions in general) directly resulted in an
ability to "express the initial prototype more quickly"
(whatever that is intended to mean).

Well an application, for the writer, is a series of statements.
The first proofs of concept for all the features is a prototype,
and if your naming convention is economical, you can express
(the statements of) those proofs more quickly and in less space.
And the relationship with an ability to optimise for speed is?
>You have not demonstrated that any "particular naming convention"
(or that your particular naming convention) has any benefits
(presumably resulting in the quicker expression of prototypes)
that cannot be found in other naming conventions.
That still stands.

<snip>
>>>>The code is closer to english and no matter how well
you get to know any computer language, english will
be clearer, especially when you've been away from the
project for a while or someone else takes over some of
it.

Leading $ symbols are "nearer to English"?

No but single words with punctuation between are clearer
than javascript method calls.
<snip>
>If camel-case really were an issue we would already be
habitually using underscores to separate words in
Identifiers.

That's not my issue, my issue is how much each "word" is
doing. Javascript method calls are a single action,
Even a single action must have something to act upon.
but often three or four words mashed together. Using the
context of a specific function or application, that action
could be given a simpler, more readable label.
Certainly a function contained within a limited scope, where its use
must be limited to code in the same scope (and physical separation could
not be too great) might use a general name that would be ambiguous in
other contexts.

But then, have we been talking about a context restricted use of a
naming convention? In this very thread you proposed the function names -
$ - and - $del - without even knowing the context of the application
being written.

<snip>
Most simple web applications, such as email and message
board programs could benefit from a basic windowing system,
it's doesn't require anything heavy or complicated, which was
the point of my example application.
Neither requires an in-browser windowing system, so introducing a
dependency on limited browser support and client-side scripting is
acting to restrict the general viability of the end result for no
apparent reason other than that it can be done.

Richard.
Aug 12 '06 #23

This discussion thread is closed

Replies have been disabled for this discussion.