Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #24521

Re: Difference between two arrays

Show all headers | View raw

Spamless wrote:
^^^^^^^^
This is Usenet.  Please fix.

> On 2014-05-31, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>> There are no built-in associative arrays in ECMAScript (ES). 
>> ??????[???]??? is the bracket ???property accessor??? syntax for *all*
>> objects (ES); it is _not_ an ???array operator??? (Flanagan).

Your newsreader is borken.  There were Unicode characters in my posting 
where there are question marks in your quotation, and they were properly 
declared.  (So much for your understanding Unicode.)

> Again, you are in the wrong group.

Nonsense.
 
> The ECMAScript group is elsewhere.

This is the international JavaScript newsgroup.

This is also the international ECMAScript newsgroup.  It has become that in 
1997 CE, when Netcape JavaScript 1.1 became one of two implementations of 
ECMAScript (the other was Microsoft JScript 1.0).  Since then, there have 
been other ECMAScript implementations, most notably Opera ECMAScript 
(discontinued), Mozilla JavaScript (successor to Netscape JavaSCript in 
Mozilla-based software), KDE JavaScript, Apple/WebKit JavaScriptCore, and 
Google V8 JavaScript.

This is also the international DOM (Document Object Model) newsgroup as far 
as ECMAScript is concerned, because the DOM API is primarily used with 
ECMAScript implementations as the DOM is primarily used in Web browsers 
which is the runtime environment that primarily employs them.  (So much that 
the “type” attribute of the HTML5 “script” element is optional and an 
ECMAScript implementation is now officially the default scripting language.)  
And AFAIK there is no DOM-specific newsgroup that would cover *all* DOM 
implementations that can be used with ECMAScript implementations (primarily, 
in Web browsers).

I think it is also the international JScript newsgroup now because 
<news:microsoft.public.scripting.jscript> not only looks quite dead (which 
might be due to the fact that Microsoft shut down many of their newsgroups a 
few years ago), but also may not be carried by all news servers.
 
> (Are you the one that thinks that Javascript supports UTF-16?,
>  16 bit Unicode?

I am certainly not someone who believes that, because I know for a fact that 
there is no Javascript.

>  Only four functions do and it is not 16 bit codepoints. It is a 16 bit
>  encoding of unicode.

UTF-16 *is* the 16-bit encoding of Unicode, whereas “16-bit” means 16-bit 
code *units*, _not_ code points:

<http://www.unicode.org/faq/utf_bom.html>

ECMAScript specifies that conforming implementations must support Unicode 
characters up to code point U+FFFF (the Basic Multilingual Plane).  The 
hexadecimal value FFFF takes two 8-bit bytes or 16 bits, and can be encoded 
in UTF-16 with one code unit.

,-<http://ecma-international.org/ecma-262/5.1/#sec-8.4>
| 
| 8.4 The String Type
| 
| The String type is the set of all finite ordered sequences of zero or more 
| 16-bit unsigned integer values (“element”). The String type is generally 
| used to represent textual data in a running ECMAScript program, in which
| case each element in the String is treated as a code unit value (see 
| Clause 6). Each element is regarded as occupying a position within the
| sequence. These positions are indexed with nonnegative integers.
| The first element (if any) is at position 0, the next element (if any) at
| position 1, and so on. The length of a String is the number of of elements 
| elements (i.e., 16-bit values) within it. The empty String has length zero
| and therefore contains no elements.
| 
| When a String contains actual textual data, each element is considered to
| be a single UTF-16 code unit.  Whether or not this is the actual storage
| format of a String, the characters within a String are numbered by their
| initial code unit element position as though they were represented using
| UTF-16. All operations on Strings (except as otherwise stated) treat them
| as sequences of undifferentiated 16-bit unsigned integers; they do not
| ensure the resulting String is in normalised form, nor do they ensure
| language-sensitive results.
| 
| NOTE
| The rationale behind this design was to keep the implementation of Strings
| as simple and high-performing as possible. The intent is that textual data
| coming into the execution environment from outside (e.g., user input, text
| read from a file or received over the network, etc.) be converted to
| Unicode Normalised Form C before the running program sees it. Usually this
| would occur at the same time incoming text is converted from its original
| character encoding to Unicode (and would impose no additional overhead).
| Since it is recommended that ECMAScript source code be in Normalised Form
| C, string literals are guaranteed to be normalised (if source text is
| guaranteed to be normalised), as long as they do not contain any Unicode
| escape sequences.

As for supporting code points beyond the BMP in ECMAScript implementations, 
see JSX:string/unicode.js.  (This is possible because ECMAScript speaks of 
16-bit “elements”, _not_ code points.  Characters beyond the BMP can be 
encoded with two UTF-16 code units.)

>  And believes that "escape" does not exist

escape() does exist as a proprietary, originally not Unicode-safe feature of 
several ECMAScript implementations for backwards compatibility.  A variant 
of escape() is specified in Annex B (informational, as annexes go) of the 
ECMAScript Language Specification (of the 5.1 Edition at least); this means 
that a conforming implementation does not need to implement it.  (However, 
Google V8 JavaScript in Chromium 34 does.  I should add a test case to the 
Matrix.)

The string values this variant generates for Unicode characters beyond the 
Basic Latin and Latin-1 Supplement Unicode ranges ("%uXXXX") do _not_ comply 
with RFC 3986; therefore, escape() cannot safely be used to encode URIs or 
URI components.  And given that escape() is proprietary, it cannot safely be 
used to encode Unicode characters at all (because the unescape() of another 
implementation may not support the format that is employed by escape() of 
the first implementation for characters beyond those ranges, if there are 
such methods).

The recommendation is to use the standard functions (methods of the global 
object) encodeURI() and encodeURIComponent() instead because they encode 
*all* Unicode characters to percent-encoded UTF-8 code units as specified by 
RFC 3986 that are considered “unsafe” by that standards-track RFC, and as my 
work shows they are “safe” features by now.  decodeURI() and 
decodeURIComponent() are their standard counterparts.

<http://PointedEars.de/es-matrix/?filter=URI>

>  and that "%xx" format as "escaped" data is a figment of all our, or at
>  my, imaginations?)

No, you must have completely misunderstood what I wrote back then.
 
> Your response is irrelevant.

Hardly.  As you could have found out if you had followed the reference and 
read the “Foreword and Rationale” section of the ECMAScript Support Matrix, 
when I write “ECMAScript” I mean both the standard and its implementations.

I am telling you that you cannot take an term invented out of thin air that 
does not have a proper definition *anywhere*, like “Javascript”, and apply 
it to all ECMAScript implementations without considering the differences 
between those implementations.

Although similar, those are *different* programming languages.  They are the 
result of the implementation of a language specification, a standard.  So 
*that* term *is* well-defined.  It is a special kind of standard though, 
because it allows its conforming implementation to extend it considerably 
(§2); this provision once allowed the two existing implementations to be 
considered conforming (finding common ground between Netscape and Microsoft 
was the goal of the first Edition), and now allows implementations of it to 
add features that may later be standardized (as we have seen and are seeing 
with ECMAScript Editions 5 and beyond.)

So there can be no “Javascript interpreter” because there is no 
“Javascript”.  That there was is a figment of *your* imagination because you 
are not capable or willing to understand the connections yet, 
*over*simplifiying matters so that you are able to understand what you 
otherwise could not comprehend.  You can continue to do so, but you will not 
arrive at the truth this way.  Instead, this way lies madness.
 
> Does creating an assoicative array with keys from an unordered
> list enable efficient searching of the list by looking for the
> key?

If there was such a thing as an associative array in a programming language, 
yes.  However, there is a difference between an associative array and an 
object that can work like such a data structure: by contrast to the 
associative array, the object has and inherits properties of its own that 
are *not* elements of what one might superficially consider an "associative 
array".  And as the ECMAScript syntax uses the bracket property accessor 
syntax both for accessing array elements and accessing properties (because 
array elements are just properties with decimal names in a certain range), 
one has to be aware of the fact.

IOW, in order to have only a key-value relationship in an ECMAScript 
implementation like JavaScript, you do not need an array (and chances are 
you do not want to, because Array instances have and inherit more properties 
that would interfere); you just need an object.  In the simplest case, an 
Object instance, created in conforming implementations of ECMAScript 5.1 
Edition thus:

  var obj = Object.create(null);

Or equivalents of that (see jsx.object.getDataObject() in JSX:object.js); 
the important thing here is that the prototype chain of the object is empty 
so that in the best case it neither has nor inherits properties whose names 
could interfere with "array" items.  Otherwise you need to implement the 
concept of associative array in a more elaborate way, avoiding built-in 
properties through aliasing (see JSX:map.js for an example).

> As keys are meant quickly to be found they are likely
> stored in an efficiently searchable structure.

True.
 
> If that is true, it can be used to remove the need for
> presorting followed by a bisection search.

Also true, but you employing a straw man argument and you are missing the 
point.
 
> Some people use it.

It is an unfortunate truth that most people do not know what they are doing.

> I take it you believe it doesn't work

I *know* from more than a decade of experience with it that it does not work 
without considering all the facts.  Using the code

  var a = new Array();

  a["foo"] = "bar";

  /* 0 */
  a["length"]

  a["0"] = "bar";

  /* 1 */
  a["length"]

  a["length"] = 0;

  /* undefined */
  a["0"]

  /* "bar" */
  a["foo"]

  a[String(Math.pow(2, 32) - 1)] = "foo";

  /* 0 */
  a["length"]

  /* "foo" */
  a[String(Math.pow(2, 32) - 1)]

  a[String(Math.pow(2, 32) - 2)] = "bar";

  /* 4294967295 */
  a["length"]

  /* "bar" */ 
  a[String(Math.pow(2, 32) - 2)] 

one can observe two things: one, that

  a["foo"] = "bar";

does _not_ add an element to an "associative array" data structure; two, 
that "somehow magically" there is already an "element" with "key" “length” 
in that supposed to be empty "associative array", and that its value 
*seemingly* changes in erratic ways as "elements" are added (and removed).  
So an uninitiated observer who is quick to jump to conclusions would 
conclude from those observations that “Javascript” has associative arrays 
but that “Javascript” is a bit borken.  (The record shows.)

Of course, nothing is borken here and nothing is flawed but the 
understanding and logic of that observer.  Both observations are *actually* 
due to the fact that it is _not_ an associative array at all; it is an 
*object* with *properties* of which some are special.  (See ES 5.1, §15.4 
for details.)

> (much as you believe that decodeURIComponent(escape(string))
> cannot possibly be used to convert UTF8 encoded text to
> Javascript strings - in UTF16 which Javascript may not
> properly recognize).

Certainly it is possible to use decodeURI() and decodeURIComponent() to 
decode UTF-8 code units that are *percent-encoded according to RFC 3986*; 
that is their very purpose.

However, it is not the purpose of escape() to encode Unicode text like that, 
not least because it predates Unicode support in ECMAScript implementations.  
So if “decodeURIComponent(escape(string))” works, it is mere coincidence; in 
general, it should only work if the characters in “string” all have code 
points below U+0080 (i. e., are in the ASCII range).

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Difference between two arrays Andrew Poulos <ap_prog@hotmail.com> - 2014-05-27 11:55 +1000
  Re: Difference between two arrays Denis McMahon <denismfmcmahon@gmail.com> - 2014-05-27 05:58 +0000
  Re: Difference between two arrays John C <rescattered@gmail.com> - 2014-05-27 03:34 -0700
    Re: Difference between two arrays Spamless <Spamless@Nil.nil> - 2014-05-31 06:35 -0500
      Re: Difference between two arrays Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-05-31 14:57 +0200
        Re: Difference between two arrays Spamless <Spamless@Nil.nil> - 2014-06-01 03:43 -0500
          Re: Difference between two arrays Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-01 14:01 +0200
            Re: Difference between two arrays Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-01 16:53 +0200
  Re: Difference between two arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-05-27 13:41 +0100
    Re: Difference between two arrays Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-05-27 17:41 +0200
    Re: Difference between two arrays Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-05-27 17:49 +0200
      Re: Difference between two arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-05-27 17:34 +0100
        Re: Difference between two arrays Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-05-27 19:33 +0200
          Re: Difference between two arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-05-27 20:03 +0100
    Re: Difference between two arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-05-27 17:16 +0100
      Re: Difference between two arrays Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-05-27 19:29 +0200
  Re: Difference between two arrays Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-05-27 17:21 +0200
  Re: Difference between two arrays Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-05-28 18:22 +0100
    Re: Difference between two arrays Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-05-30 22:23 +0100
    Re: Difference between two arrays "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-05-31 14:59 -0700
      Re: Difference between two arrays "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-06-01 00:50 +0200
        Re: Difference between two arrays "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-05-31 16:17 -0700
          Re: Difference between two arrays "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-06-01 10:49 +0200
            Re: Difference between two arrays "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-06-01 13:37 -0700
      Re: Difference between two arrays Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-06-01 18:56 +0100

csiph-web