How a delete a object from DOM ?

[Cylix]

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.

[Cylix]

Re: How a delete a object from DOM ?

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 );

[Ray]

Re: How a delete a object from DOM ?

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.removeChi ld(tbody.childN odes[2]);

Ray

[darwinist@gmail.com]

Re: How a delete a object from DOM ?

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.getEle mentById(id);}
function $del(id) {$(id).parentNo de.removeChild( $(id));}
</script>

Usage:
<script>
$del(ObjectIDSt ring);
</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

[Richard Cornford]

Re: How a delete a object from DOM ?

darwinist@gmail .com wrote:
<snip>

Two-line function library:
<script>
function $(id){return document.getEle mentById(id);}
function $del(id) {$(id).parentNo de.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.

[darwinist@gmail.com]

Re: How a delete a object from DOM ?

Richard Cornford wrote:

darwinist@gmail .com wrote:
<snip>

Two-line function library:
<script>
function $(id){return document.getEle mentById(id);}
function $del(id) {$(id).parentNo de.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.

[Richard Cornford]

Re: How a delete a object from DOM ?

darwinist@gmail .com wrote:

Richard Cornford wrote:

>darwinist@gmail .com wrote:
><snip>

Two-line function library:
<script>
function $(id){return document.getEle mentById(id);}
function $del(id) {$(id).parentNo de.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.

[darwinist]

Re: How a delete a object from DOM ?

Richard Cornford wrote:

darwinist@gmail .com wrote:

Richard Cornford wrote:

darwinist@gmail .com wrote:
<snip>
Two-line function library:
<script>
function $(id){return document.getEle mentById(id);}
function $del(id) {$(id).parentNo de.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.getEle mentById() 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.

[Richard Cornford]

Re: How a delete a object from DOM ?

darwinist wrote:

Richard Cornford wrote:

>darwinist@gmail .com wrote:

>>Richard Cornford wrote:
>>>darwinist@gmail .com wrote:
>>>>Two-line function library:
>>>><script>
>>>>function $(id){return document.getEle mentById(id);}
>>>>function $del(id) {$(id).parentNo de.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
>>>identifier s in non-machine generated Identifiers. ...

<snip>

>>I disagree,

>>
>The existence of the convention in the language's
>specificatio n 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
>specificatio n 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:-

removeDomElemen tById("soemthin g);

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.getEle mentById() for such a common task.

I may if I did. A quick text search for '.getElementByI d(' 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.

[darwinist]

Re: How a delete a object from DOM ?

Richard Cornford wrote:

darwinist wrote:

Richard Cornford wrote:

darwinist@gmail .com wrote:
>Richard Cornford wrote:
>>darwinist@gmail .com wrote:
>>>Two-line function library:
>>><script>
>>>function $(id){return document.getEle mentById(id);}
>>>function $del(id) {$(id).parentNo de.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:-
>
removeDomElemen tById("soemthin g);
>
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.getEle mentById() for such a common task.

>
I may if I did. A quick text search for '.getElementByI d(' 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.

[Richard Cornford]

Re: How a delete a object from DOM ?

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("somethin g");
>>
>- is inherently obscure, It just needs comparing with
>alternatives such as:-
>>
>removeDomEleme ntById("soemthi ng);
>>
>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 - removeDomElemen tById("soemthin g); - 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
>>>>productiv e.
>>>>
>>>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.

[darwinist]

Re: How a delete a object from DOM ?

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:-
>
removeDomElemen tById("soemthin g);
>
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(elemen t);"
is fairly clear to any programmer where
"removeDomEleme ntById(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(elemen t)" 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 - removeDomElemen tById("soemthin g); - 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(tagnam e, 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.

[Andrew Poulos]

Re: How a delete a object from DOM ?

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

[justme33]

Re: How a delete a object from DOM ?


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.h eader, 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.

[darwinist]

Re: How a delete a object from DOM ?

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