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:
|
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 |
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? |
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'. |
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> |
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
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 |
14:19 | <sideshowbarker> | by "interned" I just meant that 40 + 2 always returns the same "reference" as 42, so equality just works |
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 |
14:21 | <Ashley Claymore> | You can't change a string value, but you can change which value a property refers to. |
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)> |
|
14:26 | <sideshowbarker> | ah yeah |