separation

Discussion in 'Javascript' started by Dave, Jan 30, 2010.

  1. Dave

    Dave Guest

    Gang,

    I'm trying to split the text in a select object's list but can't
    seem to find the right combination. I'm using FF (haven't tested with
    IE) and will give some code below. Anyone that can help with this, I
    would greatly be appreciated.

    The select object's list is created (successfully) with a 'for' loop
    in php using the following code:

    print "<option value='$val'>".$name[0]."&nbsp;".$name[1]."&nbsp;".$name
    [2]."&nbsp;".$name[3]."</option>\n";

    As the above code denotes, the $val variable contains a certain value
    that can't be altered and the display (aka text) is a person's name
    separated into first, middle, last, and suffix fields. I can tell
    that the &nbsp; are being used correctly because where names entered
    that don't have a middle name, there is an obviously larger space
    between their first and last. The javascript code I'm using is as
    follows:

    var aryName = document.getElementById('name1').options
    [document.getElementById('name1').selectedIndex].text.split(/&nbsp;/);

    The select object's name is "name1". I've tried using regular spaces
    and mixing the two, but can't figure this out. The goal I'm after is
    that when the user clicks on a persons name from the select object,
    their name (according to the value of the text) is split and put into
    several text boxes that corresponds to the persons first, middle,
    last, and suffix. I would greatly appreciate any help on resolving
    this problem.

    Thanks,
    Dave
    Dave, Jan 30, 2010
    #1
    1. Advertising

  2. Dave wrote:

    > Gang,


    Did you mean "Hello group"?

    > [...]
    > The select object's list is created (successfully) with a 'for' loop
    > in php using the following code:


    Posting PHP code in a JS group is rather pointless, for you simply can
    _not_ expect people to understand it. Especially, if you have a client-
    side problem, post the client-side code, i.e. what is possibly being
    generated by server-side code, first. However, as it happens I know my way
    around PHP, too.

    > print "<option value='$val'>".$name[0]."&nbsp;".$name[1]."&nbsp;".$name
    > [2]."&nbsp;".$name[3]."</option>\n";


    <OT>

    There are a number of unnecessary concatenations here that make this harder
    to read and potentially less efficient. In addition, you should not use
    `print' unless you are interested in its constant return value 1 (as in an
    expression).

    echo "<option value='{$val}'>{$name[0]}&nbsp;{$name[1]}"
    . "&nbsp;{$name[2]}&nbsp;{$name[3]}</option>\n";

    (There are probably better ways to do this; printf() comes to mind.)

    <http://php.net/manual/en/function.print.php>

    </OT>

    > [...]
    > var aryName = document.getElementById('name1').options
    > [document.getElementById('name1').selectedIndex].text.split(/&nbsp;/);


    This can be optimized to

    var o = document.getElementById('name1');
    var aryName = o.options[o.selectedIndex].text.split(/&nbsp;/);

    > The select object's name is "name1".


    No, that is the _element's_ _ID_. However, if `name1' would be the
    element's name (i.e., the value of its `name' attribute), you should
    use the `elements' collection instead:

    formRef.elements["name1"]...

    > I've tried using regular spaces and mixing the two, but can't figure this
    > out. The goal I'm after is that when the user clicks on a persons name
    > from the select object, their name (according to the value of the text)
    > is split and put into several text boxes that corresponds to the persons
    > first, middle, last, and suffix. I would greatly appreciate any help on
    > resolving this problem.


    `&nbsp;' is an HTML character entity reference; it is the equivalent of
    ` ' (or &#xA0). When it is parsed, it ends up as a single Unicode
    (UCS-2, really) character in the parse tree, and, as a result, in the
    document tree accessible with the DOM API. That is, `&nbsp;' is not
    contained as such in the value of the `text' property (which you could have
    found out by simply displaying it). Therefore, the split() method cannot
    find it, and the return value is _a reference to an Array instance with
    only one element_.

    <http://www.w3.org/TR/html401/sgml/entities.html>

    To display Unicode characters in Unicode-supporting ECMAScript
    implementations (of ES2 forward), you can include them verbatim or (better
    here) you need to use an escape sequence, here `\u00A0'.

    However, using `&nbsp;' does not make sense here in the first place if you
    use `&nbsp;' as delimiter everywhere. I have yet to see a renderer that
    word-wraps those entries (most notably FF's Gecko does not), so you can use
    a space character instead. This would probably also help display as the
    non-breaking space character is sometimes displayed narrower or wider than
    the space character. And should there be a renderer that word-wraps the
    value then in this case it appears to be better to encourage that than to
    generate possibly incomplete display. You should use the `white-space:
    nowrap' CSS declaration instead; if a renderer or user prefers different
    display, they can easily overwrite (or ignore) that value.


    PointedEars
    --
    Danny Goodman's books are out of date and teach practices that are
    positively harmful for cross-browser scripting.
    -- Richard Cornford, cljs, <cife6q$253$1$> (2004)
    Thomas 'PointedEars' Lahn, Jan 30, 2010
    #2
    1. Advertising

  3. Dave

    Dave Guest

    On Jan 30, 5:51 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > Dave wrote:
    > > Gang,

    >
    > Did you mean "Hello group"?
    >
    > > [...]
    > > The select object's list is created (successfully) with a 'for' loop
    > > in php using the following code:

    >
    > Posting PHP code in a JS group is rather pointless, for you simply can
    > _not_ expect people to understand it.  Especially, if you have a client-
    > side problem, post the client-side code, i.e. what is possibly being
    > generated by server-side code, first.  However, as it happens I know myway
    > around PHP, too.
    >


    I agree that one can not, obviously, expect the people here to
    understand php and as a result I only posted a single line from the
    php code to display to everyone what was going to be parsed. This
    would provide insight to anyone that offered to help to see what was
    _actually_ being sent to the browser in its most "raw" form. It is a
    very simple line of code that can be figured out easily. For anyone
    that didn't understand it, I would have been more than happy to
    explain it. Also using "possibly generated code" is not a good idea
    as that can be were the problem lies and not in the code attempting to
    be troubleshot, fixed, updated, etc.

    >
    > > print "<option value='$val'>".$name[0]."&nbsp;".$name[1]."&nbsp;".$name
    > > [2]."&nbsp;".$name[3]."</option>\n";

    >
    > <OT>
    >
    > There are a number of unnecessary concatenations here that make this harder
    > to read and potentially less efficient.  In addition, you should not use
    > `print' unless you are interested in its constant return value 1 (as in an
    > expression).
    >


    I don't see the below code being any more "readable" than the one I
    submitted, however, if you prefer to code it that way in an effort to
    help find a solution, be my guest. :) Also, all findings on echo vs
    print say that the speed difference is marginal at best. This could
    be opened for debate, however, this is the wrong place to do so. I do
    appreciate the tidbit of info on the return value though.

    >
    >   echo "<option value='{$val}'>{$name[0]}&nbsp;{$name[1]}"
    >     . "&nbsp;{$name[2]}&nbsp;{$name[3]}</option>\n";
    >
    > (There are probably better ways to do this; printf() comes to mind.)
    >
    > <http://php.net/manual/en/function.print.php>
    >
    > </OT>
    >
    > > [...]
    > > var aryName = document.getElementById('name1').options
    > > [document.getElementById('name1').selectedIndex].text.split(/&nbsp;/);

    >
    > This can be optimized to
    >
    >   var o = document.getElementById('name1');
    >   var aryName = o.options[o.selectedIndex].text.split(/&nbsp;/);
    >


    Is this really optimized? Instead of parsing a single line of code, I
    have to spend more resources and time assigning an object to a
    variable, then processing the request. This might be another echo vs
    print situation. :)

    >
    > > The select object's name is "name1".

    >
    > No, that is the _element's_ _ID_.  However, if `name1' would be the
    > element's name (i.e., the value of its `name' attribute), you should
    > use the `elements' collection instead:
    >


    oops! You're right. I was a victim of saying one thing and thinking
    another. :)

    >
    >   formRef.elements["name1"]...
    >
    > > I've tried using regular spaces and mixing the two, but can't figure this
    > > out.  The goal I'm after is that when the user clicks on a persons name
    > > from the select object, their name (according to the value of the text)
    > > is split and put into several text boxes that corresponds to the persons
    > > first, middle, last, and suffix.  I would greatly appreciate any helpon
    > > resolving this problem.

    >
    > `&nbsp;' is an HTML character entity reference; it is the equivalent of
    > ` ' (or &#xA0).  When it is parsed, it ends up as a single Unicode
    > (UCS-2, really) character in the parse tree, and, as a result, in the
    > document tree accessible with the DOM API.  That is, `&nbsp;' is not
    > contained as such in the value of the `text' property (which you could have
    > found out by simply displaying it).  Therefore, the split() method cannot
    > find it, and the return value is _a reference to an Array instance with
    > only one element_.
    >


    I did display it and you're right that &nbsp; was not in the output.
    However, I did find that when using &nbsp; over a space character, I
    was able to preserve the correct amount of spaces between the
    different parts of the name so when it was parsed, the parts of the
    names could be separated correctly. I also tried to use &nbsp; over a
    regular space because what would happen if the person had two middle
    names that wasn't hyphenated? Instead of there only being 4 parts to
    the name (first, middle, last, suffix), now there would be 5. Now we
    have a bug...

    >
    > <http://www.w3.org/TR/html401/sgml/entities.html>
    >
    > To display Unicode characters in Unicode-supporting ECMAScript
    > implementations (of ES2 forward), you can include them verbatim or (better
    > here) you need to use an escape sequence, here `\u00A0'.
    >
    > However, using `&nbsp;' does not make sense here in the first place if you
    > use `&nbsp;' as delimiter everywhere.  I have yet to see a renderer that
    > word-wraps those entries (most notably FF's Gecko does not), so you can use
    > a space character instead.  This would probably also help display as the
    > non-breaking space character is sometimes displayed narrower or wider than
    > the space character.  And should there be a renderer that word-wraps the
    > value then in this case it appears to be better to encourage that than to
    > generate possibly incomplete display.  You should use the `white-space:
    > nowrap' CSS declaration instead; if a renderer or user prefers different
    > display, they can easily overwrite (or ignore) that value.
    >


    In regards to &nbsp; not making sense as a delimiter, see the above
    reply. In this situation, I'm not interested in word wrapping as the
    text value is a value to an option in a select form object (which I've
    never seen word wrapped options in a select/listbox/combobox). I most
    likely will have to keep the &nbsp; or one of your afore mentioned
    escape sequences so that the output to the user is normal (ie "first
    middle last suffix" instead of something like
    "first_middle_last_suffix"). Using &nsbp; (or an escape sequence)
    provides the normal appearance while providing a character to split
    the string correctly.

    >
    > PointedEars
    > --
    > Danny Goodman's books are out of date and teach practices that are
    > positively harmful for cross-browser scripting.
    >  -- Richard Cornford, cljs, <cife6q$253$1$> (2004)



    Dave

    PS.
    I did end up getting it to work in FF (haven't tested IE or Opera
    yet) by keeping the &nbsp; in the print statement of the php code and
    using the \u00A0 as the javascript split "character". Thanks for the
    info on the escape codes! Can anyone see any issues with doing it
    this way?
    Dave, Jan 31, 2010
    #3
  4. Dave wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> Dave wrote:
    >> > [...]
    >> > The select object's list is created (successfully) with a 'for' loop
    >> > in php using the following code:

    >>
    >> Posting PHP code in a JS group is rather pointless, for you simply can
    >> _not_ expect people to understand it. Especially, if you have a client-
    >> side problem, post the client-side code, i.e. what is possibly being
    >> generated by server-side code, first. However, as it happens I know my
    >> way around PHP, too.

    >
    > [...] It is a very simple line of code


    By whose standards?

    > that can be figured out easily.


    Again, by whose standards? Perhaps a person like you knowing (claiming to
    know) PHP in the first place? It is like asking in English in a Chinese-
    speaking newsgroup and vice-versa (both are natural languages).

    > For anyone that didn't understand it, I would have been more than happy
    > to explain it.


    Trying to force people to ask questions in order to understand your
    question is not a good strategy for asking questions. You will be more
    likely (and most likely) ignored. (Did you not wonder why there has been
    only one reply by comparison?)

    > Also using "possibly generated code" is not a good idea


    Yes, it is.

    > as that can be were the problem lies


    Yes, therefore you should post that generated code, not the generating one,
    in that case.

    > and not in the code attempting to be troubleshot, fixed, updated, etc.


    That is why I said "first"; once it has been ascertained that the generated
    code is in error, if necessary a crosspost with Followup-To can facilitate
    on-topic discussion about how the generating code (which is most likely not
    JS/ES-related) can be modified so that it generates working code.

    <OT>
    >> > print "<option value='$val'>".$name[0]."&nbsp;".$name[1]."&nbsp;"
    >> > $name[2]."&nbsp;".$name[3]."</option>\n";

    >>
    >> [...]
    >> There are a number of unnecessary concatenations here that make this
    >> harder to read and potentially less efficient. In addition, you should
    >> not use `print' unless you are interested in its constant return value 1
    >> (as in an expression).

    >
    > I don't see the below code being any more "readable" than the one I
    > submitted,


    It is no longer possible to mistake ".$name[0]." for a string literal, for
    example. However, had you used some white-space between the operands as
    suggested by e.g. PEAR Coding Standards, it could have been equally
    readable.

    > however, if you prefer to code it that way in an effort to
    > help find a solution, be my guest. :) Also, all findings on echo vs
    > print say that the speed difference is marginal at best.


    The inefficiency of your PHP code draws from the unnecessary concatenation
    (preceded by unnecessary scanning for variable references in double-quoted
    strings that do not contain any such reference), not the choice of
    function.
    </OT>

    >> > [...]
    >> > var aryName = document.getElementById('name1').options
    >> > [document.getElementById('name1').selectedIndex].text.split(/&nbsp;/);

    >>
    >> This can be optimized to
    >>
    >> var o = document.getElementById('name1');
    >> var aryName = o.options[o.selectedIndex].text.split(/&nbsp;/);

    >
    > Is this really optimized?


    Most certainly.

    > Instead of parsing a single line of code,


    ECMAScript implementations do not care about code lines with regard to
    delimited expressions.

    > I have to spend more resources and time assigning an object to a
    > variable,


    The object _reference_ is assigned to the variable, following only one-time
    scope chain traversal for `document', only one-time prototype chain
    traversal for `getElementById', and only one-time [[Call]]ing the reference
    in which this lookup results. This gain is compensated afterwards twice by
    only short-circuited, comparably easily cacheable, scope chain traversal
    for `o' (up to the Variable Object of the current execution context), and
    before by only one additional variable instantiation (sic!).

    > then processing the request.


    There is no request involved.

    > This might be another echo vs print situation. :)


    It isn't. Calling a function twice to return the very same value is
    inefficient at best to begin with; I daresay, that holds true for any
    programming language. Even more if the function is a DOM method which
    needs to traverse the document tree (to find the corresponding element
    object), should the reference value not be internally cached.

    >> `&nbsp;' is an HTML character entity reference; it is the equivalent of
    >> ` ' (or &#xA0). When it is parsed, it ends up as a single Unicode
    >> (UCS-2, really) character in the parse tree, and, as a result, in the
    >> document tree accessible with the DOM API. That is, `&nbsp;' is not
    >> contained as such in the value of the `text' property (which you could
    >> have found out by simply displaying it). Therefore, the split() method
    >> cannot find it, and the return value is _a reference to an Array
    >> instance with only one element_.

    >
    > I did display it and you're right that &nbsp; was not in the output.


    That should have indicated to you that it probably fails because you cannot
    split on something that simply is not there.

    > However, I did find that when using &nbsp; over a space character, I
    > was able to preserve the correct amount of spaces between the
    > different parts of the name so when it was parsed, the parts of the
    > names could be separated correctly.


    How can that possibly be significant here?

    > I also tried to use &nbsp; over a regular space because what would happen
    > if the person had two middle names that wasn't hyphenated? Instead of
    > there only being 4 parts to the name (first, middle, last, suffix), now
    > there would be 5. Now we have a bug...


    ACK

    >> However, using `&nbsp;' does not make sense here in the first place if
    >> you use `&nbsp;' as delimiter everywhere. I have yet to see a renderer
    >> that word-wraps those entries (most notably FF's Gecko does not), so you
    >> can use a space character instead. This would probably also help
    >> display as the non-breaking space character is sometimes displayed

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    >> narrower or wider than the space character. [...]

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    >
    > [...] Using &nsbp; (or an escape sequence) provides the normal

    ^^^^^^^^^^
    > appearance while providing a character to split the string correctly.

    ^^^^^^^^^^
    >


    No, it does not.

    >> [...]

    > I did end up getting it to work in FF (haven't tested IE or Opera
    > yet) by keeping the &nbsp; in the print statement of the php code and
    > using the \u00A0 as the javascript split "character".


    There is no "javascript", and there is no reason to put the word in quotes
    here.

    > Thanks for the info on the escape codes!


    You are welcome.

    > Can anyone see any issues with doing it this way?


    I have already told you.


    Please trim your quotes to the necessary minimum to retain context;
    summarize (with `[summary]') where necessary. Do not quote signatures
    (unless you refer to them directly).

    <http://jibbering.com/faq/#posting>


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Jan 31, 2010
    #4
  5. Dave

    Dave Guest

    On Jan 31, 5:54 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > PointedEars
    > --
    >     realism:    HTML 4.01 Strict
    >     evangelism: XHTML 1.0 Strict
    >     madness:    XHTML 1.1 as application/xhtml+xml
    >                                                     -- Bjoern Hoehrmann




    Oh you're an arguer... Good luck with that...

    Dave
    Dave, Feb 1, 2010
    #5
  6. Dave wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> PointedEars
    >> --
    >> realism: HTML 4.01 Strict
    >> evangelism: XHTML 1.0 Strict
    >> madness: XHTML 1.1 as application/xhtml+xml
    >> -- Bjoern Hoehrmann


    That's a signature (considered not part of the posting), which would have
    been obvious had you not used buggy Google Groups. Why did you quote it
    anyway?

    > Oh you're an arguer... Good luck with that...


    If you are out of good (counter-)arguments, that is *your* problem.


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Feb 1, 2010
    #6
  7. On Sun, 31 Jan 2010 at 23:54:24, in comp.lang.javascript, Thomas
    'PointedEars' Lahn wrote:

    <snip>
    >There is no "javascript", and there is no reason to put the word in quotes
    >here.

    <snip>

    Why do you object to the word 'javascript' as the generic name for a lot
    of different languages ?

    You can't say 'ECMAScript based languages' because some implementations
    in use were produced before there was an ECMA standard, and many were
    produced before the current ECMA standard settled down. The current ISO
    standard, ISO/IEC 16262:2002, is not derived from the current ECMA
    standard either.

    John
    --
    John Harris
    John G Harris, Feb 1, 2010
    #7
  8. Dave

    Dave Guest

    On Feb 1, 10:25 am, Thomas 'PointedEars' Lahn <>
    wrote:
    > Dave wrote:
    > > Thomas 'PointedEars' Lahn wrote:
    > >> PointedEars
    > >> --

    >
    > That's a signature (considered not part of the posting), which would have
    > been obvious had you not used buggy Google Groups.  Why did you quote it
    > anyway?
    >
    > > Oh you're an arguer...  Good luck with that...

    >
    > If you are out of good (counter-)arguments, that is *your* problem.
    >
    > PointedEars
    > --



    lol and my point is confirm! I have "counter arguments", but thats
    just what this would become... an argument, not a debate or anything
    healthy. One of us has to be the adult in this situation and not "add
    fuel to fire". At this point, you aren't helping any further by your
    posts. They're condescending and useless. You did help by providing
    information on the use of the escape codes, which I appreciate.
    However, the OP has been resolved and now I'm looking for additional
    comments/concerns with why using &nbsp; as a delimiter might cause
    problems. So far you have failed to help with this. Unless you're
    going to add something positive in the form of an answer or resolution
    (or even constructive Creticism), please stop posting to the thread.

    By the way, it's obvious that your technical knowledge is very good
    (give credit where credit is due). If you would work on your
    communication skills, you would help more hinder.

    http://dictionary.reference.com/browse/etiquette

    Dave
    Dave, Feb 1, 2010
    #8
  9. John G Harris wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> There is no "javascript", and there is no reason to put the word in
    >> quotes here.

    >
    > Why do you object to the word 'javascript' as the generic name for a lot
    > of different languages ?


    It is promoting the misconception that there is only one programming
    language to consider.

    > You can't say 'ECMAScript based languages' because some implementations
    > in use were produced before there was an ECMA standard


    Those were JavaScript 1.0 (and perhaps 1.1) and JScript 1.0, which are no
    longer of any practical concern.

    > and many were produced before the current ECMA standard settled down.


    The current _ECMAScript_ standard (ES5) is not of concern regarding the
    terminology.

    Only two (or three) implementations were produced before ECMAScript
    Edition 1 which was an attempt to standardize features they had in
    common. I daresay that makes them implementations of ECMAScript.


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Feb 1, 2010
    #9
  10. Dave wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> Dave wrote:
    >> > Thomas 'PointedEars' Lahn wrote:
    >> >> PointedEars
    >> >> --

    >>
    >> That's a signature (considered not part of the posting), which would
    >> have been obvious had you not used buggy Google Groups. Why did you
    >> quote it anyway?
    >>
    >> > Oh you're an arguer... Good luck with that...

    >>
    >> If you are out of good (counter-)arguments, that is *your* problem.
    >> [...]

    >
    > lol and my point is confirm!

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    No, if anything your lack of knowledge about the English language and
    Usenet etiquette has been confirmed.

    > I have "counter arguments", but thats
    > just what this would become... an argument, not a debate or anything
    > healthy.


    A (healthy) debate *consists of* arguments and counter-arguments
    (cf. Aristotle et al.) "Argument" is a word with different meanings;
    check your dictionary.


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
    Thomas 'PointedEars' Lahn, Feb 1, 2010
    #10
  11. On Mon, 1 Feb 2010 at 18:54:05, in comp.lang.javascript, Thomas
    'PointedEars' Lahn wrote:
    >John G Harris wrote:
    >
    >> Thomas 'PointedEars' Lahn wrote:
    >>> There is no "javascript", and there is no reason to put the word in
    >>> quotes here.

    >>
    >> Why do you object to the word 'javascript' as the generic name for a lot
    >> of different languages ?

    >
    >It is promoting the misconception that there is only one programming
    >language to consider.


    You'll need to use a long phrase then, such as 'the class of languages
    that extend some version of ECMAScript or a close relative'. That's far
    too long for general use; you then need a short identifier. Several of
    us think that 'javascript' is a suitable short identifier.

    I know that a plural word would be more accurate, but the singular is
    common practice in class names. Think Number for a type with many
    values, Boolean with two values. Null is unusual with only one value.

    You think that some people will think that 'javascript' is one language.
    Well, that's what the FAQ is for. Also, you ought to be screaming more
    loudly about a name that that is too easily confused with Java.


    >> You can't say 'ECMAScript based languages' because some implementations
    >> in use were produced before there was an ECMA standard

    >
    >Those were JavaScript 1.0 (and perhaps 1.1) and JScript 1.0, which are no
    >longer of any practical concern.


    So you decree that we aren't allowed to include them in general
    statements?

    Are you saying that we must say that getFullYear has always been there?


    >> and many were produced before the current ECMA standard settled down.

    >
    >The current _ECMAScript_ standard (ES5) is not of concern regarding the
    >terminology.


    It must be if you want to say ECMAScript-based.


    >Only two (or three) implementations were produced before ECMAScript
    >Edition 1 which was an attempt to standardize features they had in
    >common. I daresay that makes them implementations of ECMAScript.


    No it doesn't. You can't have an implementation of something that
    doesn't exist yet.

    John
    --
    John Harris
    John G Harris, Feb 2, 2010
    #11
  12. John G Harris wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> John G Harris wrote:
    >>> Thomas 'PointedEars' Lahn wrote:
    >>>> There is no "javascript", and there is no reason to put the word in
    >>>> quotes here.
    >>> Why do you object to the word 'javascript' as the generic name for a
    >>> lot of different languages ?

    >> It is promoting the misconception that there is only one programming
    >> language to consider.

    >
    > You'll need to use a long phrase then, such as 'the class of languages
    > that extend some version of ECMAScript or a close relative'.


    No, you won't.

    > That's far too long for general use; you then need a short identifier.


    Non sequitur. "ECMAScript implementation" suffices.

    > Several of us think that 'javascript' is a suitable short identifier.


    There is no "us". You really are pitiable, calling for big brother.

    > I know that a plural word would be more accurate,


    Good. Why don't you have the courage of your convictions?

    > but the singular is common practice in class names.


    It's not a class name.

    > Think Number for a type with many values, Boolean with two values. Null
    > is unusual with only one value.


    Neither identifier is a class name. You don't know what you are talking
    about.

    > You think that some people will think that 'javascript' is one language.


    Undoubtedly most people will think that as there are, of course, more
    people who don't know these languages well than who do.

    > Well, that's what the FAQ is for.


    If "javascript" enters common use, there will be occurences of it where
    there is no FAQ reference to explain it. That is the problem with the FAQ
    (author) inventing a term out of lazyness and trying to spread it without
    thinking that through.

    I have already seen the misconceptions to which wrong/invented terminology
    has lead, so one does not need to be an augur to say what is likely going
    to happen if this misuse continues. See, for example, position #2 in
    <news:, where the author of the reviewed
    code attributed standards-compliant, implementation-specific behavior to a
    bug in the other runtime environment because of an obvious misconception
    about a single programming language named "Javascript" that they thought
    they used.

    > also, you ought to be screaming more loudly about a name that that is too
    > easily confused with Java.


    Nonsense.

    >>> You can't say 'ECMAScript based languages' because some implementations
    >>> in use were produced before there was an ECMA standard

    >> Those were JavaScript 1.0 (and perhaps 1.1) and JScript 1.0, which are
    >> no longer of any practical concern.

    >
    > So you decree that we aren't allowed to include them in general
    > statements?


    (The strong "we" again. You are such a luser.)

    No, I am merely saying that your argument is flawed.

    > Are you saying that we must say that getFullYear has always been there?


    (See above.)

    Of course not. However, it is not reasonable to assume that there is still
    an implementation in use that does not support this method. Providing a
    reasonable, traceable basis for such recommendations, in contrast to a mere
    gut feeling, is one important reason why I am maintaining the ECMAScript
    Support Matrix.

    >>> and many were produced before the current ECMA standard settled down.

    >> The current _ECMAScript_ standard (ES5) is not of concern regarding the
    >> terminology.

    >
    > It must be if you want to say ECMAScript-based.


    I don't want to say that, you do.

    >> Only two (or three) implementations were produced before ECMAScript
    >> Edition 1 which was an attempt to standardize features they had in
    >> common. I daresay that makes them implementations of ECMAScript.

    >
    > No it doesn't. You can't have an implementation of something that
    > doesn't exist yet.


    Yes, you can; JavaScript versions 1.6 and above have proven that already.

    Besides, ECMAScript as the idea of a language standard existed long before
    a formal Specification was drafted or published, starting at the latest
    with Microsoft officially forking JavaScript 1.0 as JScript 1.0 in 1996-08.


    PointedEars
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:160
    Thomas 'PointedEars' Lahn, Feb 4, 2010
    #12
    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. Wayne Liu

    Question on view and code separation

    Wayne Liu, Jul 25, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    339
    Wayne Liu
    Jul 25, 2003
  2. tshad
    Replies:
    2
    Views:
    343
    tshad
    Dec 2, 2004
  3. Chris Ashley
    Replies:
    1
    Views:
    344
    Chris Ashley
    Aug 19, 2005
  4. Michael

    Code-separation in ASP.NET 2.0

    Michael, Nov 11, 2005, in forum: ASP .Net
    Replies:
    3
    Views:
    694
    Juan T. Llibre
    Nov 12, 2005
  5. klaas

    template separation

    klaas, Jun 28, 2003, in forum: C++
    Replies:
    2
    Views:
    2,161
    Samuele Armondi
    Jun 28, 2003
Loading...

Share This Page