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

Groups > comp.lang.javascript > #29105 > unrolled thread

Re: array-like objects

Back to article view | Back to comp.lang.javascript

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: array-like objects Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2016-01-02 13:27 -0200
    Re: array-like objects Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-02 20:48 +0100
      Re: array-like objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-03 15:50 +0000
        Re: array-like objects Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-03 16:59 +0100
          Re: array-like objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-04 11:15 +0000
            Re: array-like objects Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-04 15:27 +0100
              Re: array-like objects Tim Streater <timstreater@greenbee.net> - 2016-01-04 15:57 +0000
              Re: array-like objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-05 16:47 +0000
                Re: array-like objects Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-05 20:13 +0100
                  Re: array-like objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-06 16:24 +0000
                    Re: array-like objects Aleksandro <aleksandro@gmx.com> - 2016-01-06 14:45 -0300
                    Re: array-like objects Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-06 19:27 +0100
                      Re: array-like objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-07 11:00 +0000
                  Re: array-like objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-08 17:02 +0000
                    Re: array-like objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-09 20:07 +0000
                      Re: array-like objects Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-10 09:03 +0100
                        Re: array-like objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-10 10:03 +0000
                          Re: array-like objects Andrew Poulos <ap_prog@hotmail.com> - 2016-01-10 23:21 +1100
                            Re: array-like objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-10 15:59 +0000
                      Re: array-like objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-10 15:30 +0000
                        Re: array-like objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-11 11:03 +0000
                          Re: array-like objects "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-01-11 10:36 -0800
                            Re: array-like objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-12 10:59 +0000
                              Re: array-like objects "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-01-12 12:47 +0100
                    Re: array-like objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-02-06 10:50 +0000
                      Re: array-like objects Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-09 05:01 +0100
                        Re: array-like objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-02-09 19:07 +0000
                        Re: array-like objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-02-09 19:23 +0000
    Re: array-like objects Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2016-01-03 04:26 -0800
      Re: array-like objects Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-03 16:54 +0100
        Re: array-like objects Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-04 00:18 +0100

Page 1 of 2  [1] 2  Next page →

#29105 — Re: array-like objects

On 01/01/2016 04:11 PM, Stefan Ram wrote:
>    I define an object as follows (one line of input, one line
>    of output from the firefox console):
>
> a = { length: 3 }
> Object { length: 3 }

You have declared the "a" variable using the Object literal notation, 
containing just one key/value pair: length / 3. So, a is an object 
inheriting the Object prototype. Seemingly, the same could have been 
achieved with:

var a = {};
a.length = 3;

However, to see the real length of the object, you need to write:

Object.keys(a).length // logs 1

>
>    Now I observe the following three evaluations:
>
> a[ 0 ]
> undefined
>
> a[ 1 ]
> undefined
>
> a[ 2 ]
> undefined

As noted above, "a" is an object, not an array. That's why you are 
getting undefined whenever you try to access non existent properties of 
the object. Try a['whatever'] for instance.

>
>    . So, is »a« now an »array-like object«, because it has
>    a lenght between 0 and 9007199254740991 and it has three
>    entries for the numeric keys 0 <= key < lenght, which
>    just so happen to be »undefined«?
>
> b = Array.from( a )
> Array [ undefined, undefined, undefined ]

Array.from() is supposed to be used with array-like or iterable objects 
such as Map and Set. So you cannot pass non iterable objects such as 
your "a".

When you write Array.from(a), I think JavaScript is creating an 
array-like object with the length of 3 under the hood, so that the code 
produces:

[ undefined, undefined, undefined ]

But I need to confirm that behaviour in the ECMA2015 Specification to be 
sure.

>
>    So, the only thing we require for an object to be »array-like«
>    is a length property with an appropriate value?

No, array-like objects must have:
- indexed access to elements and the property length that tells us how 
many elements the object has.
- do not have array methods such as push(), forEach() and indexOf().

See:
<http://www.2ality.com/2013/05/quirk-array-like-objects.html>



-- 
Joao Rodrigues

[toc] | [next] | [standalone]

#29108

Joao Rodrigues wrote:

> On 01/01/2016 04:11 PM, Stefan Ram wrote:
>>    I define an object as follows (one line of input, one line
>>    of output from the firefox console):
>>
>> a = { length: 3 }
>> Object { length: 3 }
> 
> You have declared the "a" variable using the Object literal notation,

No, as far as we know, he has _not_ declared a variable.  Because that would 
require “var a” or “var …, a” or “var …, a, …”.  You have been told this 
before.  Most recently, only three days ago.

> containing just one key/value pair: length / 3. So, a is an object
> inheriting the Object prototype.

No, the value of “a” (likely “a” is a user-defined property of the global 
object then) is a reference to an object inheriting from the object 
initially referred to by the value of (the property) “Object.prototype”.

> Seemingly, the same could have been achieved with:
> 
> var a = {};
> a.length = 3;

Not only seemingly.
 
> However, to see the real length of the object, you need to write:
> 
> Object.keys(a).length // logs 1

Nonsense.  You are missing the point.

>>    Now I observe the following three evaluations:
>>
>> a[ 0 ]
>> undefined
>>
>> a[ 1 ]
>> undefined
>>
>> a[ 2 ]
>> undefined
> 
> As noted above, "a" is an object, not an array.

“a” is not an object, it is an identifier.  It might also be the name of a 
property.

> That's why you are getting undefined whenever you try to access non
> existent properties of the object.

This has nothing to do with the fact that (the value of) “a” does not refer 
to an Array instance.  The question was explicitly about array-*like* 
objects.

> Try a['whatever'] for instance.

Or “a.whatever”, since “whatever” is not (going to be) a reserved word.

>> b = Array.from( a )
>> Array [ undefined, undefined, undefined ]
> 
> Array.from() is supposed to be used with array-like or iterable objects
> such as Map and Set. So you cannot pass non iterable objects such as
> your "a".

Nonsense.  Array.from() is explicitly designed to make use of references to 
such objects, to convert them them into real Array instances.
 
> When you write Array.from(a), I think JavaScript is creating an
> array-like object with the length of 3 under the hood,

No, “JavaScript” does not do anything of the sort.  Instead, a conforming 
implementation of ECMAScript 2015, such as Google V8 JavaScript, creates an 
*Array* instance with the length 3.  Because *that* is the purpose of 
*Array*.from().

> so that the code produces:
> 
> [ undefined, undefined, undefined ]

That would not be an array-*like* object, now would it?  And it is not; it 
is an Array instance; the value of the internal “[[Class]]” property is 
*obvious* from the posted console output…

> But I need to confirm that behaviour in the ECMA2015 Specification to be
> sure.

Why do you *still* not check your assumptions *before* you post?  Nobody 
needs your many misconceptions, and to waste their free time correcting 
them.

<http://www.ecma-international.org/ecma-262/6.0/#sec-array.from>
 
>>    So, the only thing we require for an object to be »array-like«
>>    is a length property with an appropriate value?
> 
> No, array-like objects must have:
> - indexed access to elements and the property length that tells us how
> many elements the object has.
> - do not have array methods such as push(), forEach() and indexOf().

Nonsense.

> See:
> <http://www.2ality.com/2013/05/quirk-array-like-objects.html>

You should stop believing blindly everything that you read or hear.

Barring a *standard* definition, an array-like object is one that behaves 
like an array at least on property read access.  Nothing more, nothing less.  
For an object in an ECMAScript implementation that means that it has 
indexes – properties whose names are unsigned integers – and that it has a 
“length” property whose value indicates the greatest next usable index.

However, fortunately, the term “array-like” is used in ECMAScript 2015 
several times, from which one can derive the definition I gave above:

| 6.2.1 The List and Record Specification Type
|
| […]
| For notational convenience an array-like syntax can be used to access List 
| elements. For example, arguments[2] is shorthand for saying the 3rd 
| element of the List arguments.

| 6.2.6 Data Blocks
| 
| […]
| For notational convenience within this specification, an array-like syntax 
| can be used to access the individual bytes of a Data Block value. This 
| notation presents a Data Block value as a 0-origined integer indexed 
| sequence of bytes. For example, if db is a 5 byte Data Block value then $
| db[2] can be used to access its 3rd byte.

| 7.1.15 ToLength ( argument )
| 
| The abstract operation ToLength converts argument to an integer suitable
| for use as the length of an array-like object. […]

| 7.3.17 CreateListFromArrayLike (obj [, elementTypes] )
| 
| The abstract operation CreateListFromArrayLike is used to create a List 
| value whose elements are provided by the indexed properties of an array-
| like object, obj. […]

| 22.1.2.1 Array.from ( items [ , mapfn [ , thisArg ] ] )
| 
| […]
| 7. Assert: items is not an Iterable so assume it is an array-like object.
| […]

| 22.2 TypedArray Objects
| 
| TypedArray objects present an array-like view of an underlying binary data 
| buffer (24.1). […]

| 22.2.2.1.1 Runtime Semantics: TypedArrayFrom( constructor, items, mapfn, 
| thisArg )
| 
| […]
| 9. Assert: items is not an Iterable so assume it is an array-like object.
| […]

| 23.1.1.1 Map ( [ iterable ] )
| 
| NOTE
| If the parameter iterable is present, it is expected to be an object that 
| implements an @@iterator method that returns an iterator object that 
| produces a two element array-like object whose first element is a value 
| that will be used as a Map key and whose second element is the value to 
| associate with that key.

| 23.3.1.1 WeakMap ( [ iterable ] )
| 
| […]
| If the parameter iterable is present, it is expected to be an object that 
| implements an @@iterator method that returns an iterator object that 
| produces a two element array-like object whose first element is a value 
| that will be used as a WeakMap key and whose second element is the value 
| to associate with that key.

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

[toc] | [prev] | [next] | [standalone]

#29117

On Sat, 02 Jan 2016 20:48:26 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Joao Rodrigues wrote:

  <snip>
>> As noted above, "a" is an object, not an array.
>
>“a” is not an object, it is an identifier.
  <snip>

There is something wrong with this assertion. Suppose someone says
  "Please talk to Thomas." 
Do you expect to hear 
  "That's nonsense! Thomas is a name, not something you can talk to."
(To be incredibly precise, Thomas is not even a name; it's a computer
representation of a name).

Equally, when the compiler sees
  a = 5;
does it say 
  "Nonsense; 'a' is an identifier. You can't change it."

  John

[toc] | [prev] | [next] | [standalone]

#29120

John Harris wrote:

> On Sat, 02 Jan 2016 20:48:26 +0100, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
>>Joao Rodrigues wrote:
>   <snip>
>>> As noted above, "a" is an object, not an array.
>>
>>“a” is not an object, it is an identifier.
>   <snip>
> 
> There is something wrong with this assertion. Suppose someone says
>   "Please talk to Thomas."
> Do you expect to hear
>   "That's nonsense! Thomas is a name, not something you can talk to."

Assuming non-strict mode, consider this:

  b = a;

If “a” "is an object", what is “b” then?  And before you reply, consider 
this:

  /* undefined */
  a.foo

  b.foo = 42;

  /* 42 */
  a.foo

> (To be incredibly precise, Thomas is not even a name; it's a computer
> representation of a name).

Incorrect, hasty generalization.  A computer is not required for “Thomas” to 
be a name.
 
> Equally, when the compiler sees
>   a = 5;
> does it say
>   "Nonsense; 'a' is an identifier. You can't change it."

Once again you are missing the point.

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

[toc] | [prev] | [next] | [standalone]

#29134

On Sun, 03 Jan 2016 16:59:02 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>John Harris wrote:
>
>> On Sat, 02 Jan 2016 20:48:26 +0100, Thomas 'PointedEars' Lahn
>> <PointedEars@web.de> wrote:
>>>Joao Rodrigues wrote:
>>   <snip>
>>>> As noted above, "a" is an object, not an array.
>>>
>>>?a? is not an object, it is an identifier.
>>   <snip>
>> 
>> There is something wrong with this assertion. Suppose someone says
>>   "Please talk to Thomas."
>> Do you expect to hear
>>   "That's nonsense! Thomas is a name, not something you can talk to."
>
>Assuming non-strict mode, consider this:
>
>  b = a;
>
>If “a” "is an object", what is “b” then?  And before you reply, consider 
>this:
>
>  /* undefined */
>  a.foo
>
>  b.foo = 42;
>
>  /* 42 */
>  a.foo

I've considered it and come to the conclusion that you are confusing
syntax and semantics. The syntax says
  identifier_b = identifier_a ;
The semantics are complicated. They say
  If    The storage area associated with identifier_a holds a 
        primitive (non-object) value
  Then  The storage area associated with identifier_b will now also 
        hold this primitive value, but a different instance of it
  Else  The object associated with identifier_a will now also be
        associated with identifier_b
        (Note : there are other ways of saying this)

You could have reminded Joao of the peculiarities of the semantics of
object assignment, but not by condemning his use of normal English
syntax.


>> (To be incredibly precise, Thomas is not even a name; it's a computer
>> representation of a name).
>
>Incorrect, hasty generalization.  A computer is not required for “Thomas” to 
>be a name.

Joao wrote a news-group article. You criticised part of it in a
newsgroup article. I commented on your criticism in a newsgroup
article. Whatever you saw in those articles were computer
representations. Obviously, that's what I was writing about. Other
representations exist but were irrelevant.

 
>> Equally, when the compiler sees
>>   a = 5;
>> does it say
>>   "Nonsense; 'a' is an identifier. You can't change it."
>
>Once again you are missing the point.

No I'm not. (See above, again)

  John

[toc] | [prev] | [next] | [standalone]

#29135

John Harris wrote:

> On Sun, 03 Jan 2016 16:59:02 +0100, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:

Attribution *line*, _not_ attribution novel. 

> The syntax says
>   identifier_b = identifier_a ;
> The semantics are complicated. They say
>   If    The storage area associated with identifier_a holds a
>         primitive (non-object) value
>   Then  The storage area associated with identifier_b will now also
>         hold this primitive value, but a different instance of it
>   Else  The object associated with identifier_a will now also be
>         associated with identifier_b
>         (Note : there are other ways of saying this)

How did you get that idea?
 
-- 
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.

[toc] | [prev] | [next] | [standalone]

#29136

In article <4796632.tdeKqXnCYY@PointedEars.de>, Thomas 'PointedEars'
Lahn <PointedEars@web.de> wrote:

>John Harris wrote:
>
>> On Sun, 03 Jan 2016 16:59:02 +0100, Thomas 'PointedEars' Lahn
>> <PointedEars@web.de> wrote:
>
>Attribution *line*, _not_ attribution novel. 

There he goes again.

-- 
Lady Astor: "If you were my husband I'd give you poison." Churchill: "If
you were my wife, I'd drink it."

[toc] | [prev] | [next] | [standalone]

#29148

On Mon, 04 Jan 2016 15:27:13 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>John Harris wrote:
>
>> On Sun, 03 Jan 2016 16:59:02 +0100, Thomas 'PointedEars' Lahn
>> <PointedEars@web.de> wrote:
>
>Attribution *line*, _not_ attribution novel. 

Agent won't let me make it one line. If you don't like it complain to
Forte.


>> The syntax says
>>   identifier_b = identifier_a ;
>> The semantics are complicated. They say
>>   If    The storage area associated with identifier_a holds a
>>         primitive (non-object) value
>>   Then  The storage area associated with identifier_b will now also
>>         hold this primitive value, but a different instance of it
>>   Else  The object associated with identifier_a will now also be
>>         associated with identifier_b
>>         (Note : there are other ways of saying this)
>
>How did you get that idea?

By reading ECMA 262. Where don't you agree?

  John

[toc] | [prev] | [next] | [standalone]

#29150

John Harris wrote:

> On Mon, 04 Jan 2016 15:27:13 +0100, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
>> John Harris wrote:
>>> On Sun, 03 Jan 2016 16:59:02 +0100, Thomas 'PointedEars' Lahn
>>> <PointedEars@web.de> wrote:
>> Attribution *line*, _not_ attribution novel.
> 
> Agent won't let me make it one line.

I strongly doubt that your software is that b0rked that it would not allow 
you to edit that part of the posting before you submit it, if all else 
fails.

> If you don't like it complain to Forte.

Why should *I*?  *You* would be the user using software intended for use 
with Usenet that is as far as is known inadequate to the task.  So, short of 
stopping to post to Usenet, *you* can find out how to configure the software 
appropriately (there are newsgroups for that if the software manual does not 
suffice), work around its flaws (e.g., with MorVer; since it is unfree 
closed source software, you cannot edit and recompile the source code), edit 
the attribution before posting, switch to better software, or complain to 
the vendor.  Since it is Forté Agent, and Forté *Free* Agent, you paid for 
the software, so you have a right to good product quality and it is *your* 
privilege and responsibility to exercise that right.

Reasonably, my choice as one of your readers includes only to killfile you 
for not doing either of that, since *you* are making threads in which *you* 
participate harder to read.

>>> The syntax says
>>>   identifier_b = identifier_a ;
>>> The semantics are complicated. They say
>>>   If    The storage area associated with identifier_a holds a
>>>         primitive (non-object) value
>>>   Then  The storage area associated with identifier_b will now also
>>>         hold this primitive value, but a different instance of it
>>>   Else  The object associated with identifier_a will now also be
>>>         associated with identifier_b
>>>         (Note : there are other ways of saying this)
>>
>>How did you get that idea?
> 
> By reading ECMA 262.

If you think that ECMA-262 (which Edition?) is confirming your ideas, then 
you will have no difficulty citing the corresponding algorithms and 
referring explicitly to the relevant parts.

> Where don't you agree?

I do not agree with your idea as a whole.  Also, ECMAScript does not specify 
implementation behavior in such a detail as that would hinder the 
flexibility of implementations, so it is highly doubtful at best that you 
can substantiate your claim.

In particular, for an implementation it is far easier to always copy the 
memory content on simple assignment, and have the memory content define what 
type of ECMAScript value is being stored.  IOW, it stands to reason that 
object references are simply values and only treated specially in a property 
access.

For example, although my C is a bit rusty, different to your idea, in C it 
makes a lot more sense to me to handle an ECMAScript value as one of a type 
struct with fields for the values of every built-in primitive type except 
String, one pointer field for String (since IIRC, strings in C of arbitrary 
length are implemented as pointers of char) and one for object types, the 
latter two pointing to an address in the heap where the memory area for the 
actual object value starts, and finally one field indicating the stored type 
(so that you know which of the value fields of the struct contains or refers 
to the stored value; I would define and use numeric constants for that).  
Then, when the identifier reference has been resolved to a value, you look 
at the type field of the struct and determine what to do if the identifier 
is the base of a property access (values of built-in primitive types need to 
be converted to values of corresponding built-in object types internally 
before property access is possible; or, maybe you can save more memory and 
runtime if you always treat values as objects to begin with – IIRC, someone 
here has posted their research on a major implementation to that effect).

In any case, your newest attempt of trying to shift the burden of proof is 
unsuccessful.

<https://yourlogicalfallacyis.com/burden-of-proof>

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

[toc] | [prev] | [next] | [standalone]

#29153

On Tue, 05 Jan 2016 20:13:17 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>John Harris wrote:
>
>> On Mon, 04 Jan 2016 15:27:13 +0100, Thomas 'PointedEars' Lahn
>> <PointedEars@web.de> wrote:
>>> John Harris wrote:
>>>> On Sun, 03 Jan 2016 16:59:02 +0100, Thomas 'PointedEars' Lahn
>>>> <PointedEars@web.de> wrote:
>>> Attribution *line*, _not_ attribution novel.
>> 
>> Agent won't let me make it one line.
>
>I strongly doubt that your software is that b0rked that it would not allow 
>you to edit that part of the posting before you submit it, if all else 
>fails.

It appears that physical line lengths are built in to Agent. They
conform to the relevant standards.


>> If you don't like it complain to Forte.
>
>Why should *I*?
  <snip>

You are the one who complains that Agent conforms to Netiquette
guidelines applicable to people in the UK and USA. It's up to you to
convince Forte that the German guidelines are more important.


>*you* are making threads in which *you* 
>participate harder to read.

"Be conservative in what you send and liberal in what you receive."
And anyway, I don't believe you.


>>>> The syntax says
>>>>   identifier_b = identifier_a ;
>>>> The semantics are complicated. They say
>>>>   If    The storage area associated with identifier_a holds a
>>>>         primitive (non-object) value
>>>>   Then  The storage area associated with identifier_b will now also
>>>>         hold this primitive value, but a different instance of it
>>>>   Else  The object associated with identifier_a will now also be
>>>>         associated with identifier_b
>>>>         (Note : there are other ways of saying this)
>>>
>>>How did you get that idea?
>> 
>> By reading ECMA 262.
>
>If you think that ECMA-262 (which Edition?) is confirming your ideas, then 
>you will have no difficulty citing the corresponding algorithms and 
>referring explicitly to the relevant parts.

This is true.

Perhaps you are asking me to explain my conclusions. I will do this,
but it is best done in a separate article, which won't be written
today.


>> Where don't you agree?
  <snip>


>In any case, your newest attempt of trying to shift the burden of proof is 
>unsuccessful.
>
><https://yourlogicalfallacyis.com/burden-of-proof>

You asked me where I got it from. I told you. Proof of my answer
consists of witness statements and computer logs. These are private
and will not be made available here.

It is your followup implied question that has a burden-of-proof. Your
accusation fails.

("at trying", not "of trying").

  John

[toc] | [prev] | [next] | [standalone]

#29154

On 06/01/16 13:24, John Harris wrote:
> On Tue, 05 Jan 2016 20:13:17 +0100, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
> 
>> John Harris wrote:
>>
>>> On Mon, 04 Jan 2016 15:27:13 +0100, Thomas 'PointedEars' Lahn
>>> <PointedEars@web.de> wrote:
>>>> John Harris wrote:
>>>>> On Sun, 03 Jan 2016 16:59:02 +0100, Thomas 'PointedEars' Lahn
>>>>> <PointedEars@web.de> wrote:
>>>> Attribution *line*, _not_ attribution novel.
>>>
>>> Agent won't let me make it one line.
>>
>> I strongly doubt that your software is that b0rked that it would not allow 
>> you to edit that part of the posting before you submit it, if all else 
>> fails.
> 
> It appears that physical line lengths are built in to Agent. They
> conform to the relevant standards.
> 
> 
>>> If you don't like it complain to Forte.
>>
>> Why should *I*?
>   <snip>
> 
> You are the one who complains that Agent conforms to Netiquette
> guidelines applicable to people in the UK and USA. It's up to you to
> convince Forte that the German guidelines are more important.
> 
> 
>> *you* are making threads in which *you* 
>> participate harder to read.
> 
> "Be conservative in what you send and liberal in what you receive."
> And anyway, I don't believe you.

Actually, I bet nobody even notices. Thomas has the “special” ability of
making issues that nobody cares of an issue to everybody, but not
because of the issue themselves, rather by annoying the shit out of
everyone.

[toc] | [prev] | [next] | [standalone]

#29155

John Harris wrote:

> On Tue, 05 Jan 2016 20:13:17 +0100, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
>> John Harris wrote:
>>> On Mon, 04 Jan 2016 15:27:13 +0100, Thomas 'PointedEars' Lahn
>>> <PointedEars@web.de> wrote:
>>>> John Harris wrote:
>>>>> On Sun, 03 Jan 2016 16:59:02 +0100, Thomas 'PointedEars' Lahn
>>>>> <PointedEars@web.de> wrote:
>>>> Attribution *line*, _not_ attribution novel.
>>> Agent won't let me make it one line.
>> I strongly doubt that your software is that b0rked that it would not 
>> allow you to edit that part of the posting before you submit it, if all 
>> else fails.
> 
> It appears that physical line lengths are built in to Agent. They
> conform to the relevant standards.

That is not the point, and having an attribution that is long but fits in 
one line is not the goal here.  The point is that you are including 
information in the attribution that is superfluous; omitting that 
information would *easily* keep the attribution within one line.  And how 
well you know that (this is not the first time we are discussing this).

>>>>> The syntax says
>>>>>   identifier_b = identifier_a ;
>>>>> The semantics are complicated. They say
>>>>>   If    The storage area associated with identifier_a holds a
>>>>>         primitive (non-object) value
>>>>>   Then  The storage area associated with identifier_b will now also
>>>>>         hold this primitive value, but a different instance of it
>>>>>   Else  The object associated with identifier_a will now also be
>>>>>         associated with identifier_b
>>>>>         (Note : there are other ways of saying this)
>>>> How did you get that idea?
>>> By reading ECMA 262.
>> If you think that ECMA-262 (which Edition?) is confirming your ideas, 
>> then you will have no difficulty citing the corresponding algorithms
>> and referring explicitly to the relevant parts.
> 
> This is true.
> 
> Perhaps you are asking me to explain my conclusions.

No, obviously I am requiring you to substantiate your claims so that I need 
not write them off as more examples of your misconceptions about ECMAScript 
like before.

> I will do this, but it is best done in a separate article,

It belongs in this thread, where your claims were made.  A proper change of 
Subject header field value would be acceptable, though.

> which won't be written today.

No problem for me as long as it is written.  Your other alternative is very 
simple: retract your claims.

>> In any case, your newest attempt of trying to shift the burden of proof 
>> is unsuccessful.
>>
>> <https://yourlogicalfallacyis.com/burden-of-proof>
> 
> You asked me where I got it from. I told you.

No, you did not.  You made the new claim that the Specification 
substantiates your previous one, but you did not say how.  Unless you at 
least cite explicitly the parts that you think substantiate the former (a 
quotation would be of advantage, too), that new claim is only based on your 
interpretation of what you read, and your interpretation can be wrong.  As
a result, so far your previous claim also lacks substantiation.

Given that you have already claimed that ECMAScript would specify its  
conforming implementations to such a detail as memory access, which it  
obviously should not and does not, and that the implementation that is 
easier to program is one that does not implement your idea/follow your 
interpretation, your idea and interpretation are most likely wrong.

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

[toc] | [prev] | [next] | [standalone]

#29160

On Wed, 06 Jan 2016 19:27:12 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>John Harris wrote:
>
>> On Tue, 05 Jan 2016 20:13:17 +0100, Thomas 'PointedEars' Lahn
>> <PointedEars@web.de> wrote:
>>> John Harris wrote:
>>>> On Mon, 04 Jan 2016 15:27:13 +0100, Thomas 'PointedEars' Lahn
>>>> <PointedEars@web.de> wrote:
>>>>> John Harris wrote:
>>>>>> On Sun, 03 Jan 2016 16:59:02 +0100, Thomas 'PointedEars' Lahn
>>>>>> <PointedEars@web.de> wrote:
>>>>> Attribution *line*, _not_ attribution novel.
>>>> Agent won't let me make it one line.
>>> I strongly doubt that your software is that b0rked that it would not 
>>> allow you to edit that part of the posting before you submit it, if all 
>>> else fails.
>> 
>> It appears that physical line lengths are built in to Agent. They
>> conform to the relevant standards.
>
>That is not the point, and having an attribution that is long but fits in 
>one line is not the goal here.  The point is that you are including 
>information in the attribution that is superfluous; omitting that 
>information would *easily* keep the attribution within one line.  And how 
>well you know that (this is not the first time we are discussing this).

And how well you, Thomas, know that your scheme has a design flaw in
it which makes it unsuitable (this is not the first time we are
discussing this).


>>>>>> The syntax says
>>>>>>   identifier_b = identifier_a ;
>>>>>> The semantics are complicated. They say
>>>>>>   If    The storage area associated with identifier_a holds a
>>>>>>         primitive (non-object) value
>>>>>>   Then  The storage area associated with identifier_b will now also
>>>>>>         hold this primitive value, but a different instance of it
>>>>>>   Else  The object associated with identifier_a will now also be
>>>>>>         associated with identifier_b
>>>>>>         (Note : there are other ways of saying this)
>>>>> How did you get that idea?
>>>> By reading ECMA 262.
>>> If you think that ECMA-262 (which Edition?) is confirming your ideas, 
>>> then you will have no difficulty citing the corresponding algorithms
>>> and referring explicitly to the relevant parts.
>> 
>> This is true.
>> 
>> Perhaps you are asking me to explain my conclusions.
>
>No, obviously I am requiring you to substantiate your claims so that I need 
>not write them off as more examples of your misconceptions about ECMAScript 
>like before.
>
>> I will do this, but it is best done in a separate article,
>
>It belongs in this thread, where your claims were made.  

Article != thread.


>A proper change of 
>Subject header field value would be acceptable, though.
>
>> which won't be written today.
>
>No problem for me as long as it is written.  Your other alternative is very 
>simple: retract your claims.
>
>>> In any case, your newest attempt of trying to shift the burden of proof 
>>> is unsuccessful.
>>>
>>> <https://yourlogicalfallacyis.com/burden-of-proof>
>> 
>> You asked me where I got it from. I told you.
>
>No, you did not.  

For crying out loud. You said 
  "How did you get that idea?"
I told you :
  "By reading ECMA 262." 
I wish you would read what you're replying to before bashing away at
the keyboard.


  <snip>
>Given that you have already claimed that ECMAScript would specify its  
>conforming implementations to such a detail as memory access, which it  
>obviously should not and does not, 

See the Note in ECMA 262 6th edition, section 4.3.2 :-

  <quote>
4.3.2
primitive value
member of one of the types Undefined, Null, Boolean, Number, Symbol,
or String as defined in clause 6

NOTE   A primitive value is a datum that is represented directly at
the lowest level of the language implementation.
  </quote>

The lowest level in an implementation is a storage area. How storage
areas are implemented is not specified by the standard. Which is why I
didn't say "memory access".


>and that the implementation that is 
>easier to program is one that does not implement your idea/follow your 
>interpretation, your idea and interpretation are most likely wrong.

<https://yourlogicalfallacyis.com/burden-of-proof>

You need to explain why you think your description of an
implementation disagrees with what I wrote. For example, why you think
"object associated with" is somehow vastly different from "object
references" (not to be confused with References, of course).


  John

[toc] | [prev] | [next] | [standalone]

#29178

On Tue, 05 Jan 2016 20:13:17 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>John Harris wrote:
>
>> On Mon, 04 Jan 2016 15:27:13 +0100, Thomas 'PointedEars' Lahn
>> <PointedEars@web.de> wrote:
>>> John Harris wrote:

 <snip>
>>>> The syntax says
>>>>   identifier_b = identifier_a ;
>>>> The semantics are complicated. They say
>>>>   If    The storage area associated with identifier_a holds a
>>>>         primitive (non-object) value
>>>>   Then  The storage area associated with identifier_b will now also
>>>>         hold this primitive value, but a different instance of it
>>>>   Else  The object associated with identifier_a will now also be
>>>>         associated with identifier_b
>>>>         (Note : there are other ways of saying this)
>>>
>>>How did you get that idea?
>> 
>> By reading ECMA 262.
>
>If you think that ECMA-262 (which Edition?) is confirming your ideas, then 
>you will have no difficulty citing the corresponding algorithms and 
>referring explicitly to the relevant parts.
  <snip>

Here are some extracts from ECMA-262, 6th Edition / June 2015, along
with comments that explain how they justify what I wrote. The ...
symbol in the extracts indicates that some irrelevant text has been
omitted.

Note that what I wrote is only a brief description of a simple
assignment operation ( b = a; ). The full specification of the many
different cases takes several very detailed pages of ECMA 262
scattered over several sections.

People who are not interested in reading the details can go straight
to the Conclusions at the end.


First, some extracts from the terms and definitions section.


  <quote>
4.3 Terms and definitions
For the purposes of this document, the following terms and
definitions apply.

4.3.1
type
set of data values as defined in clause 6 of this specification

4.3.2
primitive value
member of one of the types Undefined, Null, Boolean, Number, Symbol,
or String as defined in clause 6

NOTE   A primitive value is a datum that is represented directly at
       the lowest level of the language implementation.

4.3.3
object
member of the type Object
  ...
  </quote>


These definitions say that 
- a type is a set of values. 
- a primitive value is held in the lowest level of the implementation.
  I.e The value occupies a single field in some kind of storage area.
- an object is a member of a type and is therefore a value.


  <quote>
4.3.30
property
part of an object that associates a key (either a String value or a
Symbol value) and a value

NOTE   Depending upon the form of the property the value may be
       represented either directly as a data value (a primitive
       value, an object, or a function object) or indirectly by a
       pair of accessor functions.
  </quote>


This definition says that the value of a property can be an object
just as a primitive value can be. Also, it shows that functions can
return an object.


That statement about properties is repeated later :


  <quote>
6.1.7  The Object Type
An Object is logically a collection of properties. Each property is
either a data property, or an accessor property:
-  A data property associates a key value with an ECMAScript
   language value and a set of Boolean attributes.
-  An accessor property associates a key value with one or two
   accessor functions, and a set of Boolean attributes. The accessor
   functions are used to store or retrieve an ECMAScript language
   value that is associated with the property.
  </quote>


Obviously ECMA 262 means what it said in the Terms and Definitions
section about objects being values.


  <quote>
6.1.7.1
Attributes are used in this specification to define and explain the 
state of Object properties. A data property associates a key value 
with the attributes listed in Table 2.

Table 2 — Attributes of a Data Property 
          Attribute Name    Value    
                            Domain Description

  [[Value]]  Any ECMAScript language type
             The value retrieved by a get access of the property.
  ...
  </quote>


Note that nowadays the value of a property is one of its attributes,
not a separate item. The attributes of a property are packaged as a
Property Descriptor, see section 6.2.4.


Is it possible for one object to be the value of two different
variables/properties? There is a specification function called
SameValue that allows it to be. 


  <quote>
7.2.9  SameValue(x, y)
The internal comparison abstract operation SameValue(x, y), where x
and y are ECMAScript language values, produces true or false. Such a
comparison is performed as follows:
    ...
  3. If Type(x) is different from Type(y), return false.
    ...
  8. If Type(x) is Boolean, then
     a. If x and y are both true or both false, return true;
        otherwise, return false.
    ...
  10. Return true if x and y are the same Object value.
      Otherwise, return false.
  </quote>


For primitive values SameValue tests whether the two representations
are the same. I've only shown the case of Boolean values; the others
follow the same theme. However, for object values things are rather
different. It's not the representations that are tested but whether
the values are the same object. Notice once again that objects are
values; the function's parameters are declared to be ECMAScript
language values, not some implementation type.

Thinking of one object being the value of two different
variables/properties is difficult and can't be pictured easily.
However this is all specification definition. The implementation can
do what it likes provided the end result is what the specification
requires and the implementation is not visible or accessible to
ECMAScript programs and programmers. The obvious implementation uses
pointers, something Thomas has described.


Now for simple assignment. Rather than use
  b = a;
as the example I will use 
  b.c = { };
There are several non-error paths through the specification of
assignment; b.c happens to be a case that is easier to follow. The
right hand side is { }, chosen to show that the specification has no
trickery in creating the value when the object first comes into
existence.


I'll start with a specification function that is used in nearly every
definition. It exits the function if an error has been seen.


  <quote>
6.2.2.4  ReturnIfAbrupt

Algorithms steps that say
  1. ReturnIfAbrupt(argument).
mean the same thing as:
  1. If argument is an abrupt completion, return argument.
  2. Else if argument is a Completion Record, let argument be 
     argument.[[value]].
  </quote> 


Now for simple assignment.


  <quote>
12.14.4  Runtime Semantics: Evaluation
AssignmentExpression[In, Yield] :
  LeftHandSideExpression[?Yield] = AssignmentExpression[?In, ?Yield]

  1. If LeftHandSideExpression is neither an ObjectLiteral nor an
     ArrayLiteral, then
     a. Let lref be the result of evaluating LeftHandSideExpression.
     b. ReturnIfAbrupt(lref).
     c. Let rref be the result of evaluating AssignmentExpression.
     d. Let rval be GetValue(rref).
     e. If IsAnonymousFunctionDefinition(AssignmentExpression) and
        IsIdentifierRef of LeftHandSideExpression are both true,
        then
        ...
     f. Let status be PutValue(lref, rval).
     g. ReturnIfAbrupt(status).
     h. Return rval.
  ...
  </quote>


The algorithm invokes a cascade of specification functions.


First, we read the source value.


  <quote>
6.2.3.1  GetValue (V)

  1. ReturnIfAbrupt(V).
  2. If Type(V) is not Reference, return V.
  ...
  <quote>


V is not a Reference here, it's the result of evaluating { }, 
like so :


  </quote>
12.2.6.8  Runtime Semantics: Evaluation
  ObjectLiteral : { }

  1. Return ObjectCreate(%ObjectPrototype%).
  <quote>


  </quote>
9.1.13  ObjectCreate(proto, internalSlotsList)
The abstract operation ObjectCreate with argument proto (an object
or null) is used to specify the runtime creation of new ordinary
objects. The optional argument internalSlotsList is a List of the
names of additional internal slots that must be defined as part of
the object. If the list is not provided, an empty List is used. This
abstract operation performs the following steps:

  1. If internalSlotsList was not provided, let internalSlotsList be
     an empty List.
  2. Let obj be a newly created object with an internal slot for
     each name in internalSlotsList.
  3. Set obj’s essential internal methods to the default ordinary
     object definitions specified in 9.1.
  4. Set the [[Prototype]] internal slot of obj to proto.
  5. Set the [[Extensible]] internal slot of obj to true.
  6. Return obj.
  <quote>


Notice that it's the newly created object that is returned here and
eventually returned by GetValue.


Finally we write the destination value. This is done by a tower of
specification function calls. Only the bottom one is interesting.


  </quote>
6.2.3.2  PutValue (V, W)
  ...
9.1.9  [[Set]]
  ...
9.1.6  [[DefineOwnProperty]]
  ...
9.1.6.1  OrdinaryDefineOwnProperty (O, P, Desc)
  ...
  </quote>


Finally, the function that actually writes the property. Remember that
Property Descriptors hold the property value as well as attributes
such as Writable, etc.


  <quote>
9.1.6.3  ValidateAndApplyPropertyDescriptor 
           (O, P, extensible, Desc, current)
When the abstract operation ValidateAndApplyPropertyDescriptor is 
called with Object O, property key P, Boolean value extensible, and 
Property Descriptors Desc, and current the following steps are taken:

This algorithm contains steps that test various fields of the 
Property Descriptor Desc for specific values. The fields that are 
tested in this manner need not actually exist in Desc. If a field is 
absent then its value is considered to be false.

NOTE 1 If undefined is passed as the O argument only validation is 
performed and no object updates are performed.
 
  ... [Much validity testing]
  10. If O is not undefined, then
      a. For each field of Desc that is present, set the
         corresponding attribute of the property named P of object O
         to the value of the field.
  11. Return true.
  </quote>


Step 10a puts the desired value into its destination. Desc was
obtained by GetValue some time ago. Remember that in this example the
value is an object.


What if the source is a property, not an object literal? The
specification functions obtain the source's value from a Property
Descriptor instead. Life's too short to show the details here.


==== Conclusions ====


The above extracts have shown that as far as ECMA 262 is concerned

- When a Variable/Property holds a primitive value it holds it in its
  own storage area.

- When a Variable/Property holds an object the Variable/Property's 
  value is the object.

- A single object can be the value of more than one Variable/Property,
  however mind boggling that might seem.

- Simple assignment treats objects as values.

I therefore conclude that my very abbreviated description of the
result of obeying the statement 
  b = a;
is entirely correct. 

  John

[toc] | [prev] | [next] | [standalone]

#29188

On 9 Jan 2016 14:52:09 GMT, ram@zedat.fu-berlin.de (Stefan Ram) wrote:

>John Harris <niam@jghnorth.org.uk.invalid> writes:
>>member of the type Object
>>  </quote>
>>These definitions say that 
>>- a type is a set of values. 
>>- a primitive value is held in the lowest level of the implementation.
>>  I.e The value occupies a single field in some kind of storage area.
>>- an object is a member of a type and is therefore a value.
>
>  A mathematical set is determined. That is, it is a specific
>  collection of entities. For example, when the set is finite,
>  it always has a certain cardinality, like, for example, 12.
>  A mathematical set does not change in time. 

True, but sets can be used to model systems that do change with time.
The changes might be modelled by a sequence. For instance, in a model
of writing a little SMS message you could have the sequence
  <"", "C", "Ca", "Cat"> 


>  Objects can be created at runtime using »new«. When the type
>  »Object« is being defined as the »set of all objects«,
>  it should be a fixed collection to be a mathematical set.
>  Not a collection that is time-dependent. 

Sets can be used to model reality but often the reality is rather
fuzzy round the edges. The set modelling all humans, past, present,
and future has this problem. Typically, as long as there are enough
members in the set it doesn't matter. If it does matter, then the
set's size can be a model parameter. Rarely would the parameter need
to be fixed to get the desired results out of the model.

In the case of ECMAScript objects we should assume that the Object
type consists of all possible objects, just as Number consists of all
possible numbers, whether used in your program or not. 

As it happens, the size of Object is known : it is countable infinity.
(Properties can hold objects, which can hold objects, and so on). Only
a miniscule number of these objects will fit into your PC. If this
matters to you, what about your next PC ?


>  But actually they also did not seem to bother to define
>  the type Object.

Well, they define objects in sec 6.1.7. At worst, this is just a
rather roundabout way of defining the type.


>>An Object is logically a collection of properties. Each property is
>...
>>Obviously ECMA 262 means what it said in the Terms and Definitions
>>section about objects being values.
>
>  But it did never seem to define »value«, it only
>  defines »primitive value«. So, when one says that
>  an object is a value, one says nothing.

Maybe they are using value in the ordinary sense used in computing
circles. They do say what goes into and what comes out of a
variable/property value in which circumstances and that's what
matters.

Maybe it's clearer to say that values can be objects, but that can
leave you wondering if objects can be something else as well.


>>Thinking of one object being the value of two different
>>variables/properties is difficult and can't be pictured easily.
>
>  Why is this more difficult than, say, »a := 2, b := 2« (in 
>  mathematics), where »2« is the value of two different names?

If you now do  a := 3  what happens to b? 

It might be unchanged, in which case a and b are in different places
and are independent of each other. The answer to the question 'Are
they the same?' has two answers : No, if you want the places to be
significant; Yes, if you don't.

On the other hand, b might change as well, in which case a and b are
synonyms. They are two names for the same place. (A C++ reference
variable is like this). In this case a and b are always the same.

But ECMAScript objects belong to neither of these cases. If you do 
a = b when a holds an object then changing the inside of the object
held by a also changes the inside of the object held by b even when a
and b are in different places. This is what's peculiar, or, at least,
what's different from numbers, strings, etc.


  John

[toc] | [prev] | [next] | [standalone]

#29201

Stefan Ram wrote:

> John Harris <niam@jghnorth.org.uk.invalid> writes:
>> But ECMAScript objects belong to neither of these cases. If you do
>> a = b when a holds an object then changing the inside of the object
>> held by a also changes the inside of the object held by b even when a
>> and b are in different places. This is what's peculiar, or, at least,
>> what's different from numbers, strings, etc.
> 
> |< a = Math
> 
>   A variable can have a value, and the value of the
>   variable »a« now is the object that also is known
>   as »Math«.

No, the value of “a” is then a reference to the same object that is referred 
to by “Math”.  *Objects have identity, not name.*

Before:

         {[built-in properties]} <--- Math
 
After:

  a ---> {[built-in properties]} <--- Math

“Math” is actually the name of a built-in property of the global object 
whose value is a reference to “the Math object”:

                                      ,----------------------------.
                                      : global object              :
                                      :----------------------------:
  a ---> {[built-in properties]} <----:-+ Math                     :
                                      : [more built-in properties] :
                                      `----------------------------'

<http://www.ecma-international.org/ecma-262/6.0/#sec-other-properties-of-the-global-object>
<http://www.ecma-international.org/ecma-262/6.0/#sec-math>
<http://www.ecma-international.org/ecma-262/6.0/#sec-math-object>

> |< b = Math
>  
>   Now the value of »b« also is the object also known as »Math«.

No, now the value of “b” is a reference to the same object that is already 
referred to by the values of “Math” and “a”:

  a ---> {[built-in properties]} <--- Math
                    ^
                    :
                    :
                    b

It really is very simple: *Object references are values.*  When an 
identifier or property access is evaluated, and the result of the evaluation 
is an object reference, and it is on the right-hand side of a simple 
assignment, then that object reference is copied and made the value of 
whatever is on the left-hand side of the assignment.  

So *there is no algorithmic difference between primitive values and object 
references with regard to simple assignment*.

<http://www.ecma-international.org/ecma-262/6.0/#sec-assignment-operators-runtime-semantics-evaluation>

>   This is possible, two different variables /can/ contain the same value.

True, but the value thus copied is _not_ the object, but the object 
*reference*.  It would be very inefficient if the entire data of an object 
would be copied on simple assignment, so that does not happen.  Instead, on 
high level, the object reference is copied, and on low level the address of 
the location in the heap memory where the object data is stored, would be 
copied.
 
> |< a.c = 27
> 
>   I set the property »c« of the value of »a« to 27,
>   thus, I set the property »c« of this object »Math«
>   to 27.

No, you set the property “c” of an object that by now is referred to by the 
values of “a”, “b“, and “Math”.

Before:

  a ---> {[built-in properties]       } <--- Math
                      ^
                      :
                      :
                      b

After:
 
  a ---> {[built-in properties], c: 27} <--- Math
                      ^
                      :
                      :
                      b

Now, in theory, you could perform a “delete” operation in succession on “a”, 
“b”, and “Math”, so that they would no longer refer to said object:

  1.     {[built-in properties], c: 27} <--- Math
                      ^
                      :
                      :
                      b

  2.     {[built-in properties], c: 27} <--- Math

  3.     {[built-in properties], c: 27}

Now the object exists in memory, but nothing refers to it.  So it can be 
marked for garbage collection, and eventually the memory reserved for it
can be freed.

> |< b.c
> |> 27
> 
>   I read the property »c« of the value of »b«, thus,
>   of this object Math.

But that would not be the case if the object were the value copied; so this 
idea is disproved.
 
-- 
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.

[toc] | [prev] | [next] | [standalone]

#29203

On Sun, 10 Jan 2016 09:03:48 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

  <snip>
>*Object references are values.*
  <snip>

The value of a variable or property cannot be an object reference say
ES2 and ES6 and every adopted edition in between.

  John

[toc] | [prev] | [next] | [standalone]

#29206

On 10/01/2016 9:03 PM, John Harris wrote:
> On Sun, 10 Jan 2016 09:03:48 +0100, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
>
>    <snip>
>> *Object references are values.*
>    <snip>
>
> The value of a variable or property cannot be an object reference say
> ES2 and ES6 and every adopted edition in between.

Yet

<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions>

says

"However, object references are values too..."

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#29211

On Sun, 10 Jan 2016 23:21:10 +1100, Andrew Poulos
<ap_prog@hotmail.com> wrote:

>On 10/01/2016 9:03 PM, John Harris wrote:
>> On Sun, 10 Jan 2016 09:03:48 +0100, Thomas 'PointedEars' Lahn
>> <PointedEars@web.de> wrote:
>>
>>    <snip>
>>> *Object references are values.*
>>    <snip>
>>
>> The value of a variable or property cannot be an object reference say
>> ES2 and ES6 and every adopted edition in between.
>
>Yet
>
><https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions>
>
>says
>
>"However, object references are values too..."

Well, it is a Mozilla JavaScript reference manual. It doesn't surprise
me in the least if Mozilla JavaScript uses pointers.

The obvious way to implement primitive string values is also to use
pointers, but I don't see Thomas banging on about that.

 John

[toc] | [prev] | [next] | [standalone]

#29210

On 9 Jan 2016 21:34:17 GMT, ram@zedat.fu-berlin.de (Stefan Ram) wrote:

>John Harris <niam@jghnorth.org.uk.invalid> writes:
>>>Why is this more difficult than, say, »a := 2, b := 2« (in 
>>>mathematics), where »2« is the value of two different names?
>>If you now do  a := 3  what happens to b? 
>
>  In order for this thread not to become too extended, I resist
>  the temptation to try to further investigate the meaning of
>  »set«, »object«, or »value«. Instead I stick with simple,
>  concrete questions, such as the one above.
>
>  In mathematics, one does not »change« the meaning of names.

No, but we are doing applied mathematics here. Names don't have to be
the names of numbers. They can be the names of a places. Think of a
blackboard; applied maths is allowed to give it a name, say BB. We are
now allowed to talk about couples (aka ordered pairs) such as 
  (BB, 42)
meaning 42 is written on the blackboard BB.


>  When »a := 2«, then one can prove that »a = 3« is false, and
>  »a := 3« can only be used in a different context, where »a := 2«
>  is not used.

Be careful with the notation. 
  a := 2  means assignment if you don't say otherwise and 
  a =d 2  means a is 2 by definition (and can't change).

With assignment you can say that the score display says (BB, 42) at 2
o'clock and has been updated to (BB, 53) at 3 o'clock. You can then
define a display function that returns the score at a given time.


>  However, one can have two (mathematical) functions »a« and
>  »b« (in mathematics), so that (think of »0« as being the time,
>  so that »0« is »0 o'clock«)
>
>a( 0 )= 2
>b( 0 )= 2
>
>  and »later« (»at 1 o'clock«):
>
>a( 1 )= 3
>
>  . The value of »b( 1 )« then is, whatever it was defined to be
>  by the definition of the function »b«. Sorry, I know that this
>  is not helpful with regard to JavaScript!

I'm not sure but I think this is saying the same thing.


>>But ECMAScript objects belong to neither of these cases. If you do 
>>a = b when a holds an object then changing the inside of the object
>>held by a also changes the inside of the object held by b even when a
>>and b are in different places. This is what's peculiar, or, at least,
>>what's different from numbers, strings, etc.
>
>|< a = Math
>
>  A variable can have a value, and the value of the
>  variable »a« now is the object that also is known
>  as »Math«.
>
>|< b = Math
> 
>  Now the value of »b« also is the object also known as
>  »Math«. This is possible, two different variables /can/
>  contain the same value.
>
>|< a.c = 27
>
>  I set the property »c« of the value of »a« to 27,
>  thus, I set the property »c« of this object »Math«
>  to 27.
>
>|< b.c
>|> 27
>
>  I read the property »c« of the value of »b«, thus,
>  of this object Math.

That's an example of what I said.


>  Mathematical values cannot change, but objects can change in
>  JavaScript. So, one could not describe this with the usual
>  mathematical notation, but with JavaScript notation one can.
>  Java or C describe this with pointers, but ECMAScript does
>  not seem to use pointers (addresses, references) to describe it.

Before doing  b = a  a has a particular mathematical value and b has
some mathematical value. After doing  b = a  a's mathematical value is
unchanged and b's mathematical value is the same as a's.

All that's changed is what you are interested in : the state before,
or the state after. No mathematical values have been harmed in the
operation of doing  b = a.

By the way, when you say 'the usual mathematical notation' I suspect
that you haven't done much really serious use of modelling with sets.
The problem of modelling system change has to be thought about and
dealt with. (And can be. Newton did it when he used immutable numbers
to model the moon going round the Earth.)

  John

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web