Array semantics — JS: Building abstractions with data

In the previous lesson, we told that an array is the easiest way to represent a point. But is it the proper way? Let's get this straight.

Keep both syntax and semantics in mind when considering language constructions, i.e., the tasks the language constructs are intended for. In practice, however, these features are often misused. This brings code that is harder to understand and debug, and therefore harder to maintain.

An (indexed) array is, in essence, a collection, a set of values having something in common, implying the possibility of enumeration and the same way of processing. In addition, these values are not strictly related to each other and can exist independently. Arrays often (but not always) lack some logical order, i.e., rigidly fixed places for their values. Or the position depends on the specific task. Here are some examples from life where arrays are appropriate:

• List of safewords
• List of users
• List of lessons in a course
• List of chess moves (order is important here)

For our graphics library, an array is suitable for storing a collection of points or a set of segments, for example.

The point itself is not a collection. It is a whole where parts do not make sense on their own. No order can be established between them, unlike, say, a list of users. And code that deals with a specific point represented by an array always expects the array to consist of two elements, each with a specific position. In other words, an array is used as a structure to describe a compound object (i.e., one that's described by more than one value, in this case by two numbers-coordinates).

In this situation, it's better to use an object:

const point = { x: 2, y: 3 };
const symmetricalPoint = { x: -point.x, y: point.y };

There is a little more code, but semantics are more important. This kind of code is easier to understand because instead of the strange point[0] or point[1] we have constructions that make more sense at first glance: point.x. Even when it's displayed on the screen, we can immediately tell what it's about.

Imagine what representing segments using arrays would look like. As an array of arrays:

const point1 = [2, 3];
const point2 = [-8, 10];
const segment = [point1, point2];

// the code is hard to understand
point1[1];
point2[0];
segment[1][0];

It's very difficult to understand that it's a segment without understanding the context. The only thing that partially salvages the situation is good variable names, but this isn't enough.

Using the right (task-appropriate) data structure is much more important:

const point1 = { x: 3, y: 4 };
const point2 = { x: -8, y: 10 };
const segment = { beginPoint: point1, endPoint: point2 };

// this code is easier to understand
point1.x;
point2.y;
segment.endPoint.y;

Remember a simple rule: code that forces you to think - confusing names, leaky abstractions, flawed data structures, and heavy reliance on context - is bad code (easiness and simplicity should not be confused here).

Using the object immediately shows another crucial advantage, it's extensible. An indexed array used as a structure is fragile. You can't swap the values because it would break all the code that expects a certain order, or you'd have to rewrite the whole thing. You can't just extend an array either: some of the code will continue to work, of course, but some of it may break (e.g., [x, y] = point). But an object doesn't rely on the order of the keys and certainly doesn't depend on the number of keys. A new key can be added at any time and the program will almost certainly remain operational.

Objects also can represent any single entity:

• User
• Course
• Lesson
• Payment
• Chess game (in addition to the date, names, and place, it also contains a set of moves)

Recommended materials

1. Simple Made Easy