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("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.


.

Relevant Pages

  • Re: How a delete a object from DOM ?
    ... machine generated means the experienced javascript programmer has to ask ... And it takes a fool to introduce a project specific style convention ... programmers. ... What is common practice? ...
    (comp.lang.javascript)
  • Re: Reply to Beth.
    ... file format, programmers who want to use the VC ide, RadAsm, WinAsm ... extra pieces of data when the vast majority of API calls are STDCALL. ... the calling convention of procedures that are not STDCALL but this is ... power of preprocessor code so that both learner programmers can get ...
    (alt.lang.asm)
  • Re: Replacing Delphi developers
    ... Good coding practice is one of those things that many people take on ... gained with age, not from sitting in lectures, nor from the choice of some ... attribute and must be learnt from other programmers, by hanging out on a ng, ...
    (comp.lang.pascal.delphi.misc)
  • Re: What will many cores mean to future Windows releases?
    ... Or if you don't like the view analogy one might think about an OPF an another sort of 'VM'--let the programmer write myObj.Save and an entire underlying layer is invoked. ... The programmers must concentrate on their human problem, ... In fact, these aren't VM anymore but, as you stated, JIT compilers. ... The gap between the best software engineering practice ...
    (borland.public.delphi.non-technical)
  • Re: When is a function not a function?
    ... The same is true for Java (indeed it appears that the idea of making provision for a conventional form to exist for machine generated code was inspired by the similar convention in Java). ... A Java programmer who disregarded that convention would be derided, but unfortunately a sufficiently large proportion of javascript 'programmers' are unprofessional that these faults can seem tolerable. ... of new keywords, I would probably start all my identifiers ...
    (comp.lang.javascript)