How a delete a object from DOM ?

Discussion in 'Javascript' started by Cylix, Aug 3, 2006.

  1. Cylix

    Cylix Guest

    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, Aug 3, 2006
    #1
    1. Advertising

  2. Cylix

    Cylix Guest

    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);
    Cylix, Aug 3, 2006
    #2
    1. Advertising

  3. Cylix

    Ray Guest

    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 <TR> from the <TBODY>? E.g. for the third row, if
    tbody refers to the TBODY element:

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

    Ray
    Ray, Aug 3, 2006
    #3
  4. Cylix

    Guest

    Cylix wrote:
    > I have a 4row x 1col table, I would like to drop all the content of row
    > three.
    > Since Mac IE5.2 does not suppport deleteRow method,
    > I have also try to set the innerHTML=''; but it does not work.
    >
    > How can I delete the node from DOM in other way?
    > Thanks.


    Two-line function library:
    <script>
    function $(id){return document.getElementById(id);}
    function $del(id) {$(id).parentNode.removeChild($(id));}
    </script>

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

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

    hth

    http://darwinist.googlepages.com/htmldesktop.html
    , Aug 3, 2006
    #4
  5. wrote:
    <snip>
    > Two-line function library:
    > <script>
    > function $(id){return document.getElementById(id);}
    > function $del(id) {$(id).parentNode.removeChild($(id));}
    > </script>

    <snip>

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

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

    Richard.
    Richard Cornford, Aug 3, 2006
    #5
  6. Cylix

    Guest

    Richard Cornford wrote:
    > wrote:
    > <snip>
    > > Two-line function library:
    > > <script>
    > > function $(id){return document.getElementById(id);}
    > > function $del(id) {$(id).parentNode.removeChild($(id));}
    > > </script>

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


    I disagree, i find it highly intuitive to group functions which handle
    dom-related elements, and it works across browsers.

    You can talk in vague theory about obscure code and confused
    programmers but I'm not convinced. I challenge you to find an obscure
    line in this entire windowing system:
    http://darwinist.googlepages.com/htmldesktop.html

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


    An important consideration, and one of which I was not aware. On the
    other hand, it runs like lightning in firefox and microsoft will
    readily admit their browser update is long overdue. I'm not
    particularly interested in coding to the bugs of a product whose
    manufacturers don't even pretend it's good anymore.

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

    > Richard.
    , Aug 4, 2006
    #6
  7. wrote:
    > Richard Cornford wrote:
    >> wrote:
    >> <snip>
    >> > Two-line function library:
    >> > <script>
    >> > function $(id){return document.getElementById(id);}
    >> > function $del(id) {$(id).parentNode.removeChild($(id));}
    >> > </script>

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

    >
    > I disagree,


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

    > i find it highly intuitive to group functions which handle
    > dom-related elements, and it works across browsers.


    What 'works' is not really an issue. Making up your own conventions is
    your choice, but disregarding well known and established conventions
    will make your personal conventions act against the wider readability of
    your code for programmers who are familiar with the well known and
    established conventions.

    > You can talk in vague theory about obscure code and
    > confused programmers but I'm not convinced.


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

    > I challenge you to find an obscure
    > line in this entire windowing system:
    > http://darwinist.googlepages.com/htmldesktop.html


    Don't be silly.

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

    >
    > An important consideration, and one of which I was not aware.
    > On the other hand, it runs like lightning in firefox and
    > microsoft will readily admit their browser update is long
    > overdue.


    Overdue as it may be, commercial browser scripting has to accommodate IE
    browsers. If you would prefer to work in some personal 'hobby' market
    that is up to you but that does not mean that proposing practices that
    are not suitable in a commercial environment is a good idea.

    > I'm not particularly interested in coding to the bugs of a
    > product whose manufacturers don't even pretend it's good
    > anymore.
    >
    > $del("id"); is quick and easy and allows you to be more
    > productive.


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

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

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

    Richard.
    Richard Cornford, Aug 4, 2006
    #7
  8. Cylix

    darwinist Guest

    Richard Cornford wrote:
    > wrote:
    > > Richard Cornford wrote:
    > >> wrote:
    > >> <snip>
    > >> > Two-line function library:
    > >> > <script>
    > >> > function $(id){return document.getElementById(id);}
    > >> > function $del(id) {$(id).parentNode.removeChild($(id));}
    > >> > </script>
    > >> <snip>
    > >>
    > >> As the specification for javascript (ECMA 262) explicitly states that
    > >> Identifiers beginning with the - $ - symbol are intended to signify
    > >> machine generated Identifiers it is poor javascript design to write
    > >> code that uses such identifiers in non-machine generated
    > >> Identifiers. All real javascript programmers can be expected to be
    > >> familiar with that formal convention and so bring expectations to
    > >> their reading of code that uses Identifiers that start with - $ -,
    > >> which, when disappointed, will result in wasted time and effort,
    > >> thus needlessly increasing code maintenance costs. (Not to mention
    > >> the impact of using such self-evidently obscure Identifiers in code).

    > >
    > > I disagree,

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


    I disagree that it will add to net confusion or obscurity.

    > > i find it highly intuitive to group functions which handle
    > > dom-related elements, and it works across browsers.

    >
    > What 'works' is not really an issue.


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

    > Making up your own conventions is
    > your choice, but disregarding well known and established conventions
    > will make your personal conventions act against the wider readability of
    > your code for programmers who are familiar with the well known and
    > established conventions.


    Not all conventions are of equal value. It depends on how well any
    convention is suited to the task that your code is intended to achieve.

    > > You can talk in vague theory about obscure code and
    > > confused programmers but I'm not convinced.

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


    There are lots of conventions and they don't always agree.

    > > I challenge you to find an obscure
    > > line in this entire windowing system:
    > > http://darwinist.googlepages.com/htmldesktop.html

    >
    > Don't be silly.


    Don't be puritanical.

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

    > >
    > > An important consideration, and one of which I was not aware.
    > > On the other hand, it runs like lightning in firefox and
    > > microsoft will readily admit their browser update is long
    > > overdue.

    >
    > Overdue as it may be, commercial browser scripting has to accommodate IE
    > browsers. If you would prefer to work in some personal 'hobby' market
    > that is up to you but that does not mean that proposing practices that
    > are not suitable in a commercial environment is a good idea.


    You have much more time to test and optimise for speed if you can
    express the initial applicaton at some level higher than the base
    toolkit. Methods are lame because they don't know anything about your
    application.

    > > I'm not particularly interested in coding to the bugs of a
    > > product whose manufacturers don't even pretend it's good
    > > anymore.
    > >
    > > $del("id"); is quick and easy and allows you to be more
    > > productive.

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


    a) it's a common practice (ask google if you don't believe me)
    b) it makes your code shorter and more readable
    c) you can combine it with other useful element functions, like
    $make(tagname, id); // make an element
    $input(type, name, value, [id]) // make an input
    $text(text) // make a text node
    d) this approach allows you write applications more quickly.
    e) you can then optimise for speed in any areas that are script-heavy.
    f) most programmers would know it to be a waste of time to rewrite
    something that works for style alone
    g) In this particular case, nobody would be confused for more than ten
    seconds, if at all, after which this function will save them a great
    many keystrokes, without a noticable difference in page performance.

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


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

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


    True, but to get the initial reference you often have to use id, and if
    you do this many times in a document, on various events for example,
    then you're going to get sick of typing document.getElementById() for
    such a common task.

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

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

    > Richard.
    darwinist, Aug 4, 2006
    #8
  9. darwinist wrote:
    > Richard Cornford wrote:
    >> wrote:
    >>> Richard Cornford wrote:
    >>>> wrote:
    >>>>> Two-line function library:
    >>>>> <script>
    >>>>> function $(id){return document.getElementById(id);}
    >>>>> function $del(id) {$(id).parentNode.removeChild($(id));}
    >>>>> </script>
    >>>> <snip>
    >>>>
    >>>> As the specification for javascript (ECMA 262) explicitly
    >>>> states that Identifiers beginning with the - $ - symbol
    >>>> are intended to signify machine generated Identifiers it
    >>>> is poor javascript design to write code that uses such
    >>>> identifiers in non-machine generated Identifiers. ...

    <snip>
    >>> I disagree,

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

    >
    > I disagree that it will add to net confusion or obscurity.


    Perhaps you should try trimming try quotes you reply to so that the
    context of your responses is not ambiguous.

    Confusion results form disappointing expectations. It is not
    unreasonable for someone to read the convention in the language's
    specification and expect others to follow it. When you disregard that
    convention for no good reason you are going to cause confusion, and
    delays and increased maintenance costs while that confusion is resolved.

    >>> i find it highly intuitive to group functions which
    >>> handle dom-related elements, and it works across browsers.

    >>
    >> What 'works' is not really an issue.

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


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

    >> Making up your own conventions is
    >> your choice, but disregarding well known and established conventions
    >> will make your personal conventions act against the wider
    >> readability of your code for programmers who are familiar with the
    >> well known and established conventions.

    >
    > Not all conventions are of equal value.


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

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

    > It depends on how well any convention is suited to the
    > task that your code is intended to achieve.


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

    >>> You can talk in vague theory about obscure code and
    >>> confused programmers but I'm not convinced.

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

    >
    > There are lots of conventions and they don't always agree.


    Of course not. If a formal coding standard say everyone will use one
    particular style of block indentation that it immediately precludes all
    other styles.

    >>> I challenge you to find an obscure
    >>> line in this entire windowing system:
    >>> http://darwinist.googlepages.com/htmldesktop.html

    >>
    >> Don't be silly.

    >
    > Don't be puritanical.


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

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

    $del("something");

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

    removeDomElementById("soemthing);

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

    <snip>
    >>> I'm not particularly interested in coding to the bugs of a
    >>> product whose manufacturers don't even pretend it's good
    >>> anymore.
    >>>
    >>> $del("id"); is quick and easy and allows you to be more
    >>> productive.

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

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


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

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

    Initial $ symbols are commonly abused in actual javascript code, but
    they certainly are not commonly misused for any single specific purpose.
    They can be used to reflect the use of the $ symbol in other languages
    (usually with a significant conceptual mismatch), they can be being used
    to indicate values of string type, they can be used to indicate values
    that should be regarded as internal or private. Indeed you are the first
    person I have read proposing that they be used to indicate DOM related
    functions. It is in fact this diversity of $ abuses that suggests that
    any use outside of the conventions provided in the specification is
    unwise, as no other expectation would be common.

    > b) it makes your code shorter and more readable


    Shorter maybe, but shortness at the cost of readability is not a good
    trade-off (as shortness can be machine imposed post development). While
    readability is precisely what it does not proved. There is no reason for
    a reader to see a $ symbol as having anything to do with DOM related
    functions, and very good reasons for them to see the $ symbol as having
    something to do with machine generation.

    > c) you can combine it with other useful element functions, like
    > $make(tagname, id); // make an element
    > $input(type, name, value, [id]) // make an input
    > $text(text) // make a text node


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

    > d) this approach allows you write applications more quickly.


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

    > e) you can then optimise for speed in any areas that
    > are script-heavy.


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

    > f) most programmers would know it to be a waste of time to
    > rewrite something that works for style alone


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

    > g) In this particular case, nobody would be confused for
    > more than ten seconds, if at all, after which this function
    > will save them a great many keystrokes, without a noticable
    > difference in page performance.


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

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


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

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



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

    >
    > True, but to get the initial reference you often have to
    > use id,


    No you don't. In an event driven system like a web browser the starting
    point of code execution is usually attached to the DOM elements of
    interest, or they can be recovered from the event object (with elements
    that have structural relationships to those elements being recoverable
    by reference through the DOM), and if you create an element you have a
    reference to it at that point and do not need to get another so long as
    you don't prematurely throw it away.

    > and if you do this many times in a document, on various
    > events for example, then you're going to get sick of typing
    > document.getElementById() for such a common task.


    I may if I did. A quick text search for '.getElementById(' in all the
    60,000 lines of javascript code in the web application I am working on
    at the moment shows 220 occurrences.

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


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

    Richard.
    Richard Cornford, Aug 7, 2006
    #9
  10. Cylix

    darwinist Guest

    Richard Cornford wrote:
    > darwinist wrote:
    > > Richard Cornford wrote:
    > >> wrote:
    > >>> Richard Cornford wrote:
    > >>>> wrote:
    > >>>>> Two-line function library:
    > >>>>> <script>
    > >>>>> function $(id){return document.getElementById(id);}
    > >>>>> function $del(id) {$(id).parentNode.removeChild($(id));}
    > >>>>> </script>
    > >>>> <snip>
    > >>>>
    > >>>> As the specification for javascript (ECMA 262) explicitly
    > >>>> states that Identifiers beginning with the - $ - symbol
    > >>>> are intended to signify machine generated Identifiers it
    > >>>> is poor javascript design to write code that uses such
    > >>>> identifiers in non-machine generated Identifiers. ...

    > <snip>
    > >>> I disagree,
    > >>
    > >> The existence of the convention in the language's
    > >> specification is fact.

    > >
    > > I disagree that it will add to net confusion or obscurity.

    >
    > Perhaps you should try trimming try quotes you reply to so that the
    > context of your responses is not ambiguous.


    Apologies for not being clear.

    > Confusion results form disappointing expectations. It is not
    > unreasonable for someone to read the convention in the language's
    > specification and expect others to follow it. When you disregard that
    > convention for no good reason you are going to cause confusion, and
    > delays and increased maintenance costs while that confusion is resolved.


    And I still say this is vague theory when I have presented a practical
    example, if an imperfect one, to illustrate just how much "confusion"
    would ensue before one sees that $del is delete an element and $make is
    make an element and all else in the application is clearer. It's a
    style convention, which are project specific, and unenforcable by
    interpreters as you say.

    > >>> i find it highly intuitive to group functions which
    > >>> handle dom-related elements, and it works across browsers.
    > >>
    > >> What 'works' is not really an issue.

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

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


    If the only practical difference it makes is to how some people
    interpret it, then it's a style difference, which has no place in a
    language specification. Just cause it's in a spec doesn't mean it
    should be followed, when the spec doesn't describe the actual platform
    you are writing for.

    > >> Making up your own conventions is
    > >> your choice, but disregarding well known and established conventions
    > >> will make your personal conventions act against the wider
    > >> readability of your code for programmers who are familiar with the
    > >> well known and established conventions.

    > >
    > > Not all conventions are of equal value.

    >
    > No they are not. Conventions are essentially arbitrary, they can all be
    > disregarded and leave an end result that still 'works'. And there are
    > numbers of different conventions applying to the same situations and
    > producing different results. Which conventions get followed is largely a
    > matter of authority. In a software house there likely are a set of house
    > conventions for coding in various languages, probably formalised, and
    > all programming staff are required to conform to those conventions.
    > However, the set of conventions chosen are not likely to be some
    > arbitrary notions plucked from the air and imposed as an exercise in
    > power. They will b chosen because they act to benefit the software
    > authoring/maintaining process, by making code standard in formal
    > structure, easily understood and recognisable for what it is. They will
    > be conventions that the programmers are (more or less) familiar with and
    > appreciate the motivation for.
    >
    > The act of specifically stating the convention if the language's
    > specification pretty much guarantees that any serious javascript
    > programmer will be familiar with it. From that starting point an formal
    > coding standards document that overwrites that convention with another
    > would be ill-conceived.


    Not necessarily, it depends what actual difference it makes.

    > > It depends on how well any convention is suited to the
    > > task that your code is intended to achieve.

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


    Except manipulating dom objects is so common and important that an
    obvious single symbol is very efficient. dom_make takes up more space
    on the screen without adding clarity. $make is easier to spot, as well.

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

    > >
    > > There are lots of conventions and they don't always agree.

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

    > >
    > > Don't be puritanical.

    >
    > In any substantial body of code there will be at least one line that is
    > totally obscure when taken out of context.
    >
    > But we are not interested in absolute obscurity but rather relative
    > obscurity. Your:-
    >
    > $del("something");
    >
    > - is inherently obscure, It just needs comparing with alternatives such
    > as:-
    >
    > removeDomElementById("soemthing);
    >
    > In the first case you almost know nothing without the source code for -
    > $del -, while in the second case the odds are good that the reader does
    > not have to even go an see what the functions does because its name has
    > already told them.


    Besides the fact that the this approach makes the programs much
    shorter, allowing context to be seen more quickly, anyone browsing the
    code ought to have sufficient commentary as to why something is being
    deleted, and what it is. An application must be allowed its own
    linguistic context in which things like "del" have a known meaning. In
    a file-system-based command line it would be assumed it was a file, in
    any web-application that's gui heavy, it might mean a gui element. The
    $ just makes it even more clear in the context of that particular
    project.

    > <snip>
    > >>> I'm not particularly interested in coding to the bugs of a
    > >>> product whose manufacturers don't even pretend it's good
    > >>> anymore.
    > >>>
    > >>> $del("id"); is quick and easy and allows you to be more
    > >>> productive.
    > >>
    > >> What it does for you is not relevant. It will potentially get
    > >> in the way of the productivity of a third party knowledgeable
    > >> javascript programmer attempting to maintain your code as they
    > >> will have to spend effort determining that this apparently
    > >> machine generated Identifier is not actually machine generated
    > >> (and then expend effort re-writing your code to eliminate the
    > >> faulty Identifiers).

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

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


    The latter, to return elements by id or reference. I don't know if many
    people use $make and $del and $input and $text, but I liked the idea
    and the syntax so much (being a php programmer, which I think a lot of
    js programmers are these days), that I extended the idea for my
    windowing system.

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


    Your primary argument against using the $ to denote dom elements is one
    of convention, to avoid confusing people who are experienced
    javascript programmers. What if they're experienced in these bad
    practices?

    > Initial $ symbols are commonly abused in actual javascript code, but
    > they certainly are not commonly misused for any single specific purpose.
    > They can be used to reflect the use of the $ symbol in other languages
    > (usually with a significant conceptual mismatch), they can be being used
    > to indicate values of string type, they can be used to indicate values
    > that should be regarded as internal or private. Indeed you are the first
    > person I have read proposing that they be used to indicate DOM related
    > functions. It is in fact this diversity of $ abuses that suggests that
    > any use outside of the conventions provided in the specification is
    > unwise, as no other expectation would be common.
    >
    > > b) it makes your code shorter and more readable

    >
    > Shorter maybe, but shortness at the cost of readability is not a good
    > trade-off (as shortness can be machine imposed post development). While
    > readability is precisely what it does not proved. There is no reason for
    > a reader to see a $ symbol as having anything to do with DOM related
    > functions, and very good reasons for them to see the $ symbol as having
    > something to do with machine generation.


    If you're open to the idea of project-specific style-conventions, then
    as I've said it's a matter of a few seconds to see the consistent
    convention in any application that uses the dollar sign this way. I
    propose it because so many web applications are getting so gui heavy,
    and it's the shortest, clearest means of distinction that I can see.

    > > c) you can combine it with other useful element functions, like
    > > $make(tagname, id); // make an element
    > > $input(type, name, value, [id]) // make an input
    > > $text(text) // make a text node

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


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

    > > d) this approach allows you write applications more quickly.

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


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

    > > e) you can then optimise for speed in any areas that
    > > are script-heavy.

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


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

    > > f) most programmers would know it to be a waste of time to
    > > rewrite something that works for style alone

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


    Your equation of clarity with an absolute naming convention, is close
    minded. There is much more to clarity.

    > > g) In this particular case, nobody would be confused for
    > > more than ten seconds, if at all, after which this function
    > > will save them a great many keystrokes, without a noticable
    > > difference in page performance.

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


    Lucky for me I don't care what you think I'm qualified to do.

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


    Brevity of code is not just keystrokes. You can look at more code at
    once and still see more comments and whitespace. The code is closer to
    english and no matter how well you get to know any computer language,
    english will be clearer, especially when you've been away from the
    project for a while or someone else takes over some of it.

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

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

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


    To save 10 - 20 bytes per call.

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

    > >
    > > True, but to get the initial reference you often have to
    > > use id,

    >
    > No you don't. In an event driven system like a web browser the starting
    > point of code execution is usually attached to the DOM elements of
    > interest, or they can be recovered from the event object (with elements
    > that have structural relationships to those elements being recoverable
    > by reference through the DOM), and if you create an element you have a
    > reference to it at that point and do not need to get another so long as
    > you don't prematurely throw it away.


    Interesting, I'll try to be more efficient with my references.

    > > and if you do this many times in a document, on various
    > > events for example, then you're going to get sick of typing
    > > document.getElementById() for such a common task.

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

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


    Good idea.

    > Richard.
    darwinist, Aug 7, 2006
    #10
  11. 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.
    Richard Cornford, Aug 7, 2006
    #11
  12. Cylix

    darwinist Guest

    Richard Cornford wrote:
    > darwinist wrote:
    > > Richard Cornford wrote:

    > <snip>
    > >> Confusion results form disappointing expectations. ...

    > >
    > > And I still say this is vague theory when I have presented
    > > a practical example, if an imperfect one, to illustrate just
    > > how much "confusion" would ensue before one sees that $del
    > > is delete an element and $make is make an element and all
    > > else in the application is clearer.

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

    >
    > And it takes a fool to introduce a project specific style convention
    > that contradicts a specification defined convention when numerous
    > alternative conventions could equally well (or better) achieve the same
    > function grouping without impacting existing expectations.


    Sure if they achieve it equally well.

    > >>>>> i find it highly intuitive to group functions which
    > >>>>> handle dom-related elements, and it works across browsers.
    > >>>>
    > >>>> What 'works' is not really an issue.
    > >>>
    > >>> Sorry I must have misheard you. Could you say that again?
    > >>
    > >> What 'works' is not really an issue. In allowing the inclusion
    > >> of the $ symbol in identifiers and then asserting that it
    > >> should only be used at the start of a machine generated
    > >> Identifier the specification had no choice but allow any
    > >> Identifier starting with a $ symbol to be legal. The
    > >> interpreter cannot know that an Identifier has been machine
    > >> generated, and so cannot apply special tokenising/parsing
    > >> rules for machine generated Identifiers. Using them where
    > >> they should not be used is going to 'work', it is just
    > >> something that should not be done.

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

    >
    > How people interpret code is very important to how effectively and
    > efficiently they re going to be able to maintain it. And it is not just
    > 'some people' but experienced javascript programmers, the very people
    > who are likely to be expensively be brought in to fix faults in some web
    > application.


    What development system is this where someone can't look up a function
    immediately?

    > > then it's a style difference, which has no place in a
    > > language specification.

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

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


    What they expect is one factor. Overall clarity and readability is what
    matters and I suggest a single symbol (perhaps you could name a more
    appropriate one) make this distinction clear and takes about 10 seconds
    to familiarise yourself with.

    > > when the spec doesn't describe the actual platform
    > > you are writing for.

    >
    > What?


    The javascript spec doesn't describe the actual programming platforms
    we use, not completelely. We need to write for the interpreters that
    people use, not the specs of an interpreter that should exist.

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

    > >
    > > Not necessarily, it depends what actual difference it makes.

    >
    > So what difference does using a leading $ symbol to group DOM related
    > functions make over using any other naming convention for the same
    > functions make? A leading lowercase - d - would be as short, a leading
    > underscore as short and as obscure, and a leading - dom_ - pretty short
    > and approaching self-documenting.


    Underscores could work. I tend to associate them with system calls,
    myself.

    > >>> It depends on how well any convention is suited to the
    > >>> task that your code is intended to achieve.
    > >>
    > >> Any naming convention could make DOM related method distinct
    > >> from others, and may would be less ambiguous themselves,
    > >> and all others would avoid facing the reasonable assumption
    > >> that the convention laid down in

    > >
    > > Except manipulating dom objects is so common and important
    > > that an obvious single symbol is very efficient.

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


    Well ok, but I really think its inclusion in the spec is giving it
    undue importance in your mind.

    > > dom_make takes up more space
    > > on the screen without adding clarity.

    >
    > Nonsense, the character sequence - dom - has inherent meaning to anyone
    > who is programming web browsers, and a few extra characters to render
    > code more meaningful is not that much of a cost.
    >
    > > $make is easier to spot, as well.
    > >
    > >>>>> You can talk in vague theory ...

    > <snip>
    > >> >>> I challenge you to find an obscure
    > >> >>> line in this entire windowing system:
    > >> >>> http://darwinist.googlepages.com/htmldesktop.html
    > >> >>
    > >> >> Don't be silly.
    > >> >
    > >> > Don't be puritanical.
    > >>
    > >> In any substantial body of code there will be at least
    > >> one line that is totally obscure when taken out of context.
    > >>
    > >> But we are not interested in absolute obscurity but rather
    > >> relative obscurity. Your:-
    > >>
    > >> $del("something");
    > >>
    > >> - is inherently obscure, It just needs comparing with
    > >> alternatives such as:-
    > >>
    > >> removeDomElementById("soemthing);
    > >>
    > >> In the first case you almost know nothing without the source
    > >> code for - $del -, while in the second case the odds are
    > >> good that the reader does not have to even go an see what
    > >> the functions does because its name has already told them.

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

    >
    > Shorter is not better.


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

    > > allowing context to be seen more quickly,

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


    The longer the function and method calls the more often you have to
    either split functions across lines, or calculate parameters separately
    before passing them. All this means less gets said per screen.

    > > anyone browsing the code ought to have sufficient commentary
    > > as to why something is being deleted, and what it is.

    >
    > And in the real world code gets modified in debugging and comments get
    > left as they are, so they can get out of date. Self-documenting code
    > tells you what it is doing in a way that changes with every code
    > modification. Comments are not the best approach to obscure code,
    > clearer code is.


    Both are necessary. Trying to include too much documentation in the
    code itself actually makes it less readable for things like skimming
    functions and scanning for particular lines. I agree that obscure code
    cannot be solved by comments, but if a function's purpose is relatively
    clear then the purpose of a line in it which reads "del(element)" or
    "del(list)" or even "del(x)" will be clear.

    > > An application must be allowed its own linguistic context
    > > in which things like "del" have a known meaning.

    >
    > That is of no value at all for newcomers to the code. A newcomer
    > reading - $del('something'); - is off on a chase to find out what the
    > meaning is (misdirected by their disappointed expectations), while a
    > newcomer reading - removeDomElementById("soemthing); - can go straight
    > on to reading the next line of code.


    But the chase takes a few seconds, while the more verbose function call
    will take up a bit more space and time every time it's used, and has a
    lot of words together with no spaces or other punctuation in between.

    > > In a file-system-based command line it would be assumed it
    > > was a file,

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

    >
    > Not if it first make it unclear in the context of javascript.


    Clear is a short function with descriptive comments. Clear is not a
    style-convention specific to that partiuclar language.

    > >><snip>
    > >>>>> I'm not particularly interested in coding to the bugs of a
    > >>>>> product whose manufacturers don't even pretend it's good
    > >>>>> anymore.
    > >>>>>
    > >>>>> $del("id"); is quick and easy and allows you to be more
    > >>>>> productive.
    > >>>>
    > >>>> What it does for you is not relevant. It will potentially get
    > >>>> in the way of the productivity of a third party knowledgeable
    > >>>> javascript programmer attempting to maintain your code as they
    > >>>> will have to spend effort determining that this apparently
    > >>>> machine generated Identifier is not actually machine generated
    > >>>> (and then expend effort re-writing your code to eliminate the
    > >>>> faulty Identifiers).
    > >>>
    > >>> a) it's a common practice (ask google if you don't believe me)
    > >>
    > >> What is common practice? Using initial $ symbols in javascript
    > >> code, or using initial $ symbols to indicate DOM related methods?

    > >
    > > The latter,

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

    >
    > Was that the latter?


    In a narrow sense.

    > > I don't know if many people use $make and $del and $input and
    > > $text,

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

    >
    > That sounds personal rather than 'common practice'.


    I adopted the basic dollar function idea for getting elements and
    extended it.

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

    > >
    > > Your primary argument against using the $ to denote dom
    > > elements is one of convention,

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

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


    You couldn't dismiss that possibility no matter what the variable was
    called, since you say most javascript is written by one group of poorly
    informed individuals and cut-and-pasted by another.

    > <snip>
    > > If you're open to the idea of project-specific style-conventions,
    > > then as I've said it's a matter of a few seconds to see the
    > > consistent convention in any application that uses the dollar
    > > sign this way.

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


    Geez: search-> "function $del("-> "all files in project"->"find";

    > > I propose it because so many web applications are getting
    > > so gui heavy, and it's the shortest, clearest means of
    > > distinction that I can see.

    >
    > Short is not necessarily good and clear it is not.
    >
    > >>> c) you can combine it with other useful element functions,
    > >>> like
    > >>> $make(tagname, id); // make an element
    > >>> $input(type, name, value, [id]) // make an input
    > >>> $text(text) // make a text node
    > >>
    > >> Wrapping common code structures into parameterised functions
    > >> is not an idea that requires, or justifies, a specific naming
    > >> convention. dom_make, dom_input and dom_text being just as
    > >> possible, and fractionally less obscure.

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

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


    It behaves like punctuation, and punctuation tells you about structure.
    Interacting with the gui deserves a kind of punctuation, or at least
    can benefit from one.

    > >>> d) this approach allows you write applications more quickly.
    > >>
    > >> It is well known that the maintenance costs are always a
    > >> significant factor in applications.

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

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


    Functions should not try to fit the language they are written in, but
    rather the application they are creating. That is their "natural"
    meaning.

    > >>> e) you can then optimise for speed in any areas that
    > >>> are script-heavy.
    > >>
    > >> There is no relationship between an ability to optimise for
    > >> speed and the use of any particular naming convention.

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

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


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

    > >>> f) most programmers would know it to be a waste of time
    > >>> to rewrite something that works for style alone
    > >>
    > >> Most programmers would know enough not to write something
    > >> obscurely in the first place.

    > >
    > > Your equation of clarity with an absolute naming convention,

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


    That can only be taken so far, before you are repeating yourself
    unnecessarily to anyone who has spent more than ten minutes with your
    code.

    Of course function names should have inherent meaning. What kind, how
    much, and in what context should that meaning be "inherent"? That is
    the point of contention.

    > > is close minded. There is much more to clarity.
    > >
    > >>> g) In this particular case, nobody would be confused for
    > >>> more than ten seconds, if at all, after which this function
    > >>> will save them a great many keystrokes, without a noticable
    > >>> difference in page performance.
    > >>
    > >> If you were not even aware of the IE memory leak problem I
    > >> don't think you have ever written anything with javascript
    > >> that qualifies you to make such statements about performance.

    > >
    > > Lucky for me I don't care what you think I'm qualified to do.

    >
    > You can find out in whichever way your prefer.


    Thanks

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

    > >
    > > Brevity of code is not just keystrokes. You can look at more
    > > code at once and still see more comments and whitespace.
    > > The code is closer to english and no matter how well you get
    > > to know any computer language, english will be clearer,
    > > especially when you've been away from the project for a
    > > while or someone else takes over some of it.

    >
    > Leading $ symbols are "nearer to English"?


    No but single words with punctuation between are clearer than
    javascript method calls.

    > >> >> The overall impact of having to stuff a document with an
    > >> >> excessive number of unique element IDs may be less apparent,
    > >> >> but it will act to hinder development in the longer term.
    > >> >
    > >> > So will long and complicated statements, which are inevitable
    > >> > if you stick as close as possible to the native javascript/dom
    > >> > methods when writing your applicatoin.
    > >>
    > >>
    > >> Well? Replacing re-occurring blocks of code with parameterised
    > >> function call is normal and sensible. I would question the reason
    > >> for wrapping code in a function when that function itself only
    > >> contains one line of code.

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

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


    Many javascript applications are installed across the world over
    networks and updated often. Downloadability is part of a web-pages
    usability.

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

    > Richard.
    darwinist, Aug 7, 2006
    #12
  13. 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
    Andrew Poulos, Aug 7, 2006
    #13
  14. Cylix

    justme33 Guest

    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
    , 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.
    justme33, Aug 7, 2006
    #14
  15. Cylix

    darwinist Guest

    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
    darwinist, Aug 7, 2006
    #15
  16. Cylix

    darwinist Guest

    justme33 wrote:
    > darwinist wrote:
    > > Richard Cornford wrote:
    > > > darwinist wrote:
    > > > > Richard Cornford wrote:

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


    I don't think he's a troll. Anyway, I like the freedom of usenet. BBs
    are fine, too. They're not mutually exclusive.
    darwinist, Aug 7, 2006
    #16
  17. On 07/08/2006 06:03, darwinist wrote:

    > justme33 wrote:


    [snipped pointless attributions]

    >> You can't win an arguement with the largest troll of this group.


    There are no regular trolls in this group. There is a village idiot, though.

    >> He seems to have infinite time to respond to


    One of the nice things about Usenet is that it is not a real-time medium
    (though I know that can be frustrating for those asking a question). As
    such, one can take one's time to compose a response.

    >> and confuse everything someone writes in tons of words.


    Aside from the frequent and unfortunate transposition typos (a
    consequence of typing quickly, I suppose), Richard's responses are
    rather eloquent.

    >> It is best just to not respond to him or put him on your kill file.


    If one would wish to ignore a reliable source of information, I suppose
    one could do that.

    >> He is a rather amateur troll as trolls goes.


    That would seem to be a self-description.

    >> He often is quite rude, but usually not nasty.


    He is to-the-point, as are others, and as am I. We are all adults here,
    yes? Usenet is certainly not the place for children. Surely there's no
    need for hand-holding?

    >> For instance, one of the most extreme trolls around goes by the
    >> handle of , among many others. He brags about
    >> going through 2 or more remailers. He has over 74000 posts under
    >> one name alone. He often hits hobby groups with the most dirty
    >> posts you can imagine. He often spoofs the name of group members.


    "...one of the most extreme trolls around..."? So what does any of that
    have to do with Richard?

    >> Such is Usenet.


    Any large group of people will contain morons and ne'er-do-wells. Such
    is the human race.

    [snip]

    >> However more and more people are using BBs where the posts are kept
    >> civil and trouble makers can be banned.


    I should think that more and more people are using Web-based forums
    because more and more people are using the Web without knowledge that
    Usenet exists.

    > I don't think he's a troll.


    Good; he isn't. Richard is an important contributor to this group. The
    same thing can't be said for whoever this
    person is, though.

    [snip]

    Mike
    Michael Winter, Aug 7, 2006
    #17
  18. Cylix

    justme33 Guest

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

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

    >
    > There are no regular trolls in this group. There is a village idiot, though.


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

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

    >> There are no regular trolls in this group. There is a village idiot, though.

    >
    > Perhaps there are no regular trolls from your viewpoint, although I
    > would nearly put you on the troll list from the tone of some of your
    > posts. The point is that kind and helpful posts cost no more than
    > shrill and rude ones. It has been my observation that most of the


    Why is it that you want/hope for free expert advice and then expect it
    on your terms? Don't you realise that answers to questions, even if the
    tone/attitude is not what you prefer, are the result of someone
    volunteering their time, knowledge and effort for your benefit. Pay them
    and then you can ask for it on your terms.

    > really top people in scientific and engineering areas do not resort to
    > such and do not have time to discuss minute trivia.Want-to-bes
    > sometimes try to impress with their "superior knowledge". I recall a
    > scientist years ago where I worked who was always trying to impress
    > everyone with his "superior" knowledge and kept everything in an uproar
    > by unfounded objections to what others were doing or saying that
    > usually were of trivial importance. He caused so much disruption that
    > he was given the choice of taking a course in human relations or
    > leaving. Unfortunately some use Usenet for the same purpose as the
    > person I mentioned, or as a substitute for a fight with the wife or
    > kicking the dog, which will get them into real trouble. And there
    > usually is no easy way to stop this.
    >

    Usenet and companies/institutions, that can't manage their employees,
    are not the same thing. If you are unhappy with posts on Usenet don't
    read them.

    Andrew Poulos
    Andrew Poulos, Aug 8, 2006
    #19
  20. darwinist wrote:
    > Richard Cornford wrote:

    <snip>
    >> You are basing you example on your own expectations, ...

    <snip>
    >>> It's a style convention, which are project specific,
    >>> and unenforcable by interpreters as you say.

    >
    >> And it takes a fool to introduce a project specific
    >> style convention that contradicts a specification defined
    >> convention when numerous alternative conventions could
    >> equally well (or better) achieve the same function grouping
    >> without impacting existing expectations.

    >
    > Sure if they achieve it equally well.


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

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

    >>
    >> How people interpret code is very important to how effectively
    >> and efficiently they re going to be able to maintain it.


    Inevitably, so advantages follow from the code satisfying the
    (preferably more established) expectations of the reader.

    >> And it is not just 'some people' but experienced javascript
    >> programmers, the very people who are likely to be expensively
    >> be brought in to fix faults in some web application.

    >
    > What development system is this where someone can't look up a
    > function immediately?


    Finding a function definition in a source code files does not say
    anything about how that file is created, and an indicator of a machine
    generated Identifier implies a fully or partly machine generated file
    and so the need to appreciate the how, where and why of its creation.

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

    >
    > What they expect is one factor.


    Quite an important factor.

    > Overall clarity and readability is what matters


    It is what matters. Does disappointing a reasonable expectation, while
    not providing any relevant implicit meaning (the implicit meaning of $
    being currency related) in the Identifier, really contribute to clarity
    or readability?

    > and I suggest a single symbol (perhaps you could name
    > a more appropriate one)


    I would prefer a character sequnce (More sometimes is more).

    > make this distinction clear and takes about 10
    > seconds to familiarise yourself with.


    I have already disputed your "10 seconds". I still think that you are
    seeing this only from the perspective of someone intimately familiar
    with the naming convention you have chosen to use. It is inevitable that
    you would find it easy to see things from that perspective, but you
    should also be able to see that there are advantages in being able to se
    things from other perspectives (particularly if working in GUI design).
    If you assumed no knowledge of any specific meaning to the $ symbol
    where you use it and re-examined the situation it should be fairly
    obvious that your source code gains no clarity through its use, and if
    you assumed an (any) alternative meaning that the code actually becomes
    misleading.

    Lets consider the inherent meaning of $, as indicative of a particular
    type of currency and examine your functions- $( ... ), $del(id) and
    $make( ... ). Intuition might suggest something related to accounting
    and/or currency formatting. The reaming parts of the Identifiers, the
    'del' and 'make', certainly do not preclude a fiscally related
    interpretation.

    >>> when the spec doesn't describe the actual platform
    >>> you are writing for.

    >>
    >> What?

    >
    > The javascript spec doesn't describe the actual
    > programming platforms we use, not completelely.


    The deviations between ECMA 262 and ECMAScript implementations (such as
    JavaScript(tm) and JScript) are minimal and largely of no practical
    significance. And over time the number of implementation bugs has
    diminished, with changes being towards conformance with the
    specification.

    > We need to write for the interpreters that people use,
    > not the specs of an interpreter that should exist.


    You are proposing a practical impossibility. You have no way of
    determining what interpreters people actually use, and are not in a
    position to gather enough information about all of them anyway.

    It is much more practical to write javascript to ECMA 262 and avoid the
    few areas where problems are known to exist than to attempt to
    accumulate a specific knowledge of the behaviour of all implementations
    into a useable sub-set (and even if the latter was realistic the
    outcome would likely be the same anyway).

    >><snip>
    >> So what difference does using a leading $ symbol to group
    >> DOM related functions make over using any other naming
    >> convention for the same functions make? A leading lowercase
    >> - d - would be as short, a leading underscore as short and
    >> as obscure, and a leading - dom_ - pretty short and
    >> approaching self-documenting.

    >
    > Underscores could work. I tend to associate them with system
    > calls, myself.


    The most common use of leading underscores is to indicate object
    properties that are 'private' by naming convention, and so that would be
    expectation best anticipated in others.

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

    >
    > Well ok, but I really think its inclusion in the spec is
    > giving it undue importance in your mind.


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

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

    >>
    >> Shorter is not better.

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


    Without the caveat "a properly defined context" that statement would be
    very questionable. For a start - element - would be a poor choice of
    Identifier for a value that was a string representing an ID, and -
    del(elementId); - is not unambiguously acting upon the element referred
    to by the ID string.

    >>> allowing context to be seen more quickly,

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

    >
    > The longer the function and method calls the more often you
    > have to either split functions across lines,


    Properly indented, I don't have a problem with splitting a function call
    across lines. My comment was intended to suggest that a function call
    would not often be mixed with other code on the same line (or in the
    same expression) and so that there was little need for function names to
    be too visually distinct in the source code.

    > or calculate parameters separately before passing them.
    > All this means less gets said per screen.


    <snip>
    >>>>> a) it's a common practice (ask google if you don't believe me)
    >>>>
    >>>> What is common practice? ...

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

    >>
    >> That sounds personal rather than 'common practice'.

    >
    > I adopted the basic dollar function idea for getting
    > elements and extended it.


    That sounds personal rather than 'common practice'.

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

    >
    > You couldn't dismiss that possibility no matter what the
    > variable was called,


    Without the leading $ symbol there would be no reason for introducing
    the possibility that the Identifier was machine generated.

    > since you say most javascript is written by one group of
    > poorly informed individuals and cut-and-pasted by another.


    It would also be an action against the inherent understandability of
    javascript source code to include a machine generated Identifier that
    did not commence with a $ symbol.

    >> <snip>
    >>> If you're open to the idea of project-specific
    >>> style-conventions, then as I've said it's a matter of
    >>> a few seconds to see the consistent convention in any
    >>> application that uses the dollar sign this way.

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

    >
    > Geez: search-> "function $del("-> "all files in project"->"find";


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

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

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

    >
    > It behaves like punctuation, and punctuation tells you
    > about structure. Interacting with the gui deserves a kind
    > of punctuation, or at least can benefit from one.


    That is only going to work if _every_ interaction with the DOM is
    similarly wrapped in a function call, even something as simple as
    reading a value from a form element once. Apart from the performance hit
    of doing that, you would start to get to the point where the whole set
    of functions beginning with $ symbols was so large that they needed
    distinguishing names anyway.

    >>>>> d) this approach allows you write applications more quickly.
    >>>>
    >>>> It is well known that the maintenance costs are always
    >>>> a significant factor in applications.
    >>>
    >>> Yes, which is why brevity and readability are so important.

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

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


    Which has no relationship to giving functions names that say something
    about what they do.

    > but rather the application they are creating. That is
    > their "natural" meaning.


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

    Function names should say enough to state what the function is doing at
    the point where the function is called, and without reference to the
    actual function definition.

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

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

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


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

    You have not demonstrated that any "particular naming convention" (or
    that your particular naming convention) has any benefits (presumably
    resulting in the quicker expression of prototypes) that cannot be found
    in other naming conventions.


    <snip>
    >>> Your equation of clarity with an absolute naming
    >>> convention,

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

    >
    > That can only be taken so far, before you are repeating
    > yourself unnecessarily to anyone who has spent more than
    > ten minutes with your code.


    A call to the same function is a call to the same function whatever the
    name of that function is.

    > Of course function names should have inherent meaning. What
    > kind, how much,


    Sufficient that it becomes unnecessary to cross-reference the function
    call with the function definition, certainly whenever the function
    definition is expected to be some distance form the call.

    > and in what context should that meaning be "inherent"?


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

    > That is the point of contention.


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

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

    >>
    >> Leading $ symbols are "nearer to English"?

    >
    > No but single words with punctuation between are clearer than
    > javascript method calls.


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

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

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

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

    >
    > Many javascript applications are installed across the world
    > over networks and updated often. Downloadability is part of
    > a web-pages usability.


    But given that HTTP 1.1 requires user agents and servers to support zip
    compression/decompression downloadability is (or could/should be)
    related to the post-compression nature of the source, and repetition is
    what compresses best. The practical impact of may occurrences of the
    same 10-20 characters of source text is likely to be negligible.

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


    Or; the implied necessity to integrate the existing code with the
    javascript code needed for any real application makes it particularly
    important to maximise the readability of the code, especially for the
    experienced javascript programmers who are the only people who should
    sensibly be employed in writing a web application sufficiently complex
    as to require an in-browser windowing GUI.

    Richard.
    Richard Cornford, Aug 10, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Thorsten Meininger
    Replies:
    0
    Views:
    429
    Thorsten Meininger
    Jul 28, 2004
  2. Thorsten Meininger
    Replies:
    0
    Views:
    494
    Thorsten Meininger
    Jul 28, 2004
  3. mike
    Replies:
    1
    Views:
    1,089
    Martin Honnen
    Nov 20, 2004
  4. Replies:
    0
    Views:
    534
  5. Replies:
    3
    Views:
    517
    Stefan Behnel
    Aug 3, 2007
Loading...

Share This Page