02:07
<sideshowbarker>
I’m overhauling the MDN Array article at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array and one big change I’m making is to reduce the __Description__ section down to just a bulleted list of the essential core characteristics of JavaScript arrays.
02:08
<sideshowbarker>

Here’s what I have so far:

In JavaScript, arrays are not primitives but are instead represented with Array objects, which have the following core characteristics:

  • JavaScript arrays are not fixed-length and not restricted to containing a single data type but can have a mix of data types. (When those characteristics are undesirable, use typed arrays instead.)

  • JavaScript arrays are zero-indexed: the first element of a JavaScript array is at index 0, and the last element is at the value of the array's {{jsxref("Array.length", "length")}} property minus1. See the access an array item by its index example. Using an invalid or out-range index number returns undefined.

  • JavaScript array-copy operations create shallow copies — (just as copy operations with any JavaScript objects create shallow copies): assigning an existing array to a new variable does not create a copy. Instead the new variable contains a_reference_ to the original array. If you change a value in the original array, it will be reflected in the new array. See the copy an array examples.

02:10
<Jessidhia>
probably also important to mention sparse arrays; just because length > 0 it doesn’t mean there are actually length items in it
02:10
<sideshowbarker>
probably also important to mention sparse arrays; just because length > 0 it doesn’t mean there are actually length items in it
Thanks yeah, I have that further on in a Notes section
02:12
<bterlson>
For clarity I might remove the negations in the first bullet - say what the arrays are rather than what they aren't?
02:15
<sideshowbarker>
For clarity I might remove the negations in the first bullet - say what the arrays are rather than what they aren't?
OK, will give it a try that way
02:16
<jmdyck>
Maybe mention that array elements are object properties, and that an array can have other properties as well. Or maybe that's not 'core'.
02:21
<sideshowbarker>
Maybe mention that array elements are object properties, and that an array can have other properties as well. Or maybe that's not 'core'.
will add that in the Notes section
02:27
<sideshowbarker>
Should it mention that JavaScript arrays are multidimensional?
02:28
<sideshowbarker>
hmm I guess not
02:28
<Jessidhia>
they are not, though
02:28
<sideshowbarker>
oh
02:28
<Jessidhia>
you can nest arrays but that’s not what a multidimensional array is
02:28
<sideshowbarker>
ah yeah OK
02:29
<Jessidhia>
I think C# is the only language where I remember having seen multidimensional arrays 🤔
02:29
<sideshowbarker>
yeah I meant in the sense that you can have an array of arrays — but I guess that’s true of pretty much any other language too
02:29
<sideshowbarker>
OK
02:30
<Jessidhia>
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/arrays/multidimensional-arrays
02:31
<Jessidhia>
nested arrays in C# conversely are https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/arrays/jagged-arrays
02:31
<Jessidhia>
they have different memory layouts and algorithmic complexity
09:10
<yulia>
I guess it really depends on what you want to communicate. Arrays in JS are objects with numbered fields as an implementation, but we wouldn't say that JavaScript doesn't have Arrays. As a concept, rather than an implementation, Multidimensional arrays are arrays with multiple dimensions. That can be represented as an array of arrays as in c or as a dedicated named constructor as in c#. Everything that can be represented in C# as a multidimensional array can be represented as an array of arrays where each sub array is of the same length. This difference is of implementation rather than of concept. A good discussion of different representations of this concept can be found here: https://eli.thegreenplace.net/2015/memory-layout-of-multi-dimensional-arrays/ -- a single implementation isn't the right one for all cases. With regards to terminology, Jagged arrays are a unique distinction in C# that is not commonly used in other languages, especially where there is no implementation distinction. For documentation purposes, if we need to say that javascript can, for example, represent a matrix, then the term multidimensional arrays is more useful as it is descriptive. "jagged" is less useful without first defining multidimensional, as it describes (in short hand, relative to the other datastructure) how it is different from a classic multidimensional array.
09:20
<yulia>
I am not super familiar with c#, but what they may have been trying to get across really was first class support for a matrix ++. A matrix is a well defined concept with associated algebraic transformations. You can represent one as a multidimensional array, but making it efficient would need certain adjustments that don't make sense for a simple array (which is the common case for most languages). This is a more tightly defined concept in my opinion than multidimensional array.
09:43
<Ashley Claymore>

Here’s what I have so far:

In JavaScript, arrays are not primitives but are instead represented with Array objects, which have the following core characteristics:

  • JavaScript arrays are not fixed-length and not restricted to containing a single data type but can have a mix of data types. (When those characteristics are undesirable, use typed arrays instead.)

  • JavaScript arrays are zero-indexed: the first element of a JavaScript array is at index 0, and the last element is at the value of the array's {{jsxref("Array.length", "length")}} property minus1. See the access an array item by its index example. Using an invalid or out-range index number returns undefined.

  • JavaScript array-copy operations create shallow copies — (just as copy operations with any JavaScript objects create shallow copies): assigning an existing array to a new variable does not create a copy. Instead the new variable contains a_reference_ to the original array. If you change a value in the original array, it will be reflected in the new array. See the copy an array examples.

"In JavaScript, arrays are not primitives but are instead represented with Array objects"

This reminds me of when I was first learning to program, in JS. And it was a while before I realized that arrays and regexes are 'just objects', in my mind because they had a literal version that meant they were a primitive

09:43
<Ashley Claymore>
I like to hold onto these memories
09:45
<yulia>
objects being the operative word 😬
09:46
<yulia>
I guess, i would also link what an object is there. It may be useful to have a page on javascript types and the weirdness that is 'everything is an object'
09:52
<yulia>

I think that, if you don't want to explicitly call out arrays-in-arrays and the things that can represent, then this line covers it

JavaScript arrays are not fixed-length and not restricted to containing a single data type but can have a mix of data types.

It could something to the effect that '... and can hold any mix of javascript values, including primitives, objects, functions, and other arrays'. If someone is learning about arrays for the first time, multidimensional sounds complicated. The flexibility should be explicit.

11:11
<Jessidhia>

the usual way of doing multidimensional arrays on languages without the distinction between multidimensional and jagged arrays actually is to use stride (aka pitch); you probably saw something about it if you ever did 2d graphics

nested arrays are actually pretty weird as far as representing “data with multiple dimensions” go, or at least I wouldn’t consider, say, an array of pairs an n-by-2 multidimensional array

this is more of a philosophical discussion, though 😇

11:12
<yulia>
yep, agreed!
11:13
<yulia>
when it comes to communicating with learners i would go for simpler language in any case.
11:14
<yulia>
we had a proposal to introduce stride to typed arrays, but it isn't going forwards for a few reasons
13:34
<sideshowbarker>
thanks all for the feedback about the Array article
13:35
<sideshowbarker>
another thing I’ve run into with the rewrite is, at MDN we lack a good explanation of what a “shallow copy” is, specifically for JavaScript objects
13:37
<sideshowbarker>
so as part of that, I have question: Is it accurate to state something like, “JavaScript objects can contain two broad types of things: primitives, and references to objects” ?
13:38
<sideshowbarker>
in other words, is any object member actually a reference to an object? — including one that’s an object literal? (rather than a variable)
13:41
<sideshowbarker>
for example, in let foo = ["bar", { "hoge": "moge" }], is the second array member actually a reference to a {"hoge": "moge"} object?
13:47
<Andreu Botella (he/they)>
That's right
13:48
<Andreu Botella (he/they)>
But IMO I'm not sure treating primitives and references as two separate things is necessarily the best model, at least for beginners
13:48
<Andreu Botella (he/they)>
You can treat primitives as essentially immutable interned references
13:49
<Andreu Botella (he/they)>
That doesn't work with, say, proxies, but we're talking beginners
14:04
<sideshowbarker>
I wonder if explaining interned references might be more than needed for beginners, in the context of this
14:08
<Ashley Claymore>
I quite like the model described by the JustJavascript course. How everything is a value and objects can point to other values.
14:13
<jmdyck>
i.e. you can think of a reference to the "bar" string in the same way you think of a reference to the {"hoge": "moge"} object
14:14
<jmdyck>
(But note that the spec uses "reference" in a different context.)
14:16
<sideshowbarker>
yeah — except that if you copy foo to baz, and change the "bar" in foo, the "bar" in baz doesn’t change — but if you change the {"hoge": "moge"} object in foo, it does change in baz too, right?
14:18
<Ashley Claymore>
"bar" can't be changed? only foo[0] can be changed
14:18
<jmdyck>
That's where you have to be careful with wording
14:18
<Andreu Botella (he/they)>
I wonder if explaining interned references might be more than needed for beginners, in the context of this
by "interned" I just meant that 40 + 2 always returns the same "reference" as 42, so equality just works
14:19
<sideshowbarker>
by "interned" I just meant that 40 + 2 always returns the same "reference" as 42, so equality just works
ah OK
14:20
<jmdyck>
You can't change a string value, but you can change which value a property refers to.
14:20
<sideshowbarker>
"bar" can't be changed? only foo[0] can be changed
OK yeah maybe that’s the point I need to focus on for the “shallow copy” explanation
14:21
<Ashley Claymore>
You can't change a string value, but you can change which value a property refers to.
right, and that is regardless of what type of value the property is referring to, primitive or another object.
14:22
<Ashley Claymore>
when something is shallow copied, it is as the first level of values are all 'moved' so they are also in the copy, while still remaining in the original.
14:24
<Ashley Claymore>
or from a different angle, when an object is shallow copied. Only the object itself is copied, so the copy's properties still point to the same values as the original's. again it doesn't matter if the values are objects or primitives
14:24
<sideshowbarker>
changing the value of foo[0] assigns a completely new value, while changing { "hoge": "moge" } to { "foo": "bar" } is just altering properties of the existing foo[1] value
14:25
<jmdyck>
No, { "foo": "bar"} creates a new object, doesn't affect the {"hoge":"moge"} object.
14:26
<sideshowbarker>
OK
14:26
<Andreu Botella (he/they)>
foo[1] = {"foo": "bar"};  // assigns a completely new value

// alters the existing foo[1] value
foo[1].foo = "bar";
delete foo[1].hoge;
14:26
<sideshowbarker>
ah yeah