DEV Community: Aleksandar Aleksandrov

Autovivification in JavaScript

Aleksandar Aleksandrov — Sat, 26 Dec 2020 22:14:12 +0000

Autovivification is a very long and idiosyncratic word, which simply means that each time you dereference an undefined value, automatically an object is created in it's place.

Hmm... that wasn't very clear, was it? Let see an example to get the idea, trust me it's quite simple 😊

In JavaScript you can easily do this

const non_vivified = {};
non_vivified.prop = 'value';

but can not do this

const non_vivified = {};
non_vivified.parent_prop.child_prop = 'value';
> Uncaught TypeError: non_vivified.parent_prop is undefined

And this is the case in the vast majority of programming languages. We usually prefer this approach as the latter is considered the less expected behavior.

Now one place where this is not the case is in Perl. Perl has autovivification by default and is by far the most popular example of this property (even the picture on this post shows it).

OK, now let's get back to JavaScript. Where would we like such behavior to be present 🤔 Well the most obvious answer is when you want to dynamically create big nested structures as it would save you the hassle of checking if the property exists on each step and creating it.

Alright we are almost there now, how do we add autovivification to our js objects. It's actually quite simple, we use the Proxy object that was added in ES6.

Let's first see the code and work backwards.

function autovivify() {
    return new Proxy({}, {
        get: (target, name) => {
            if (name === 'toJSON') {
                return () => target;
            } else {
                return name in target ?
                    target[name] :
                    target[name] = autovivify()
            }
        }
    })
}

What we just did is create a function that returns a new instance of a vivified object. The important part is the second object passed to the Proxy constructor. It's basically an object that describes the handlers of the Proxy. As you guessed get is the handler that is invoked when we request a property of the object. In our case if it does not exist we simply create a new Proxy object by recursively calling the autovivify function. If it exists, then simply return the property. The other important thing is the toJSON check. This is done so that we do not get a stack overflow error when calling JSON.stringify as this is the method being called when serialization happens.

Now we can do

const vivified = autovivify();
vivified.parent_prop.child_prop = 'value';

This is all nice and fine, but what if I want to vivify an already existing object. Well that is somewhat harder than expected, as we want proxies to be invisible to the caller. Or as the ES spec describes it

"It is impossible to determine whether an object is a proxy or not (transparent virtualization)."

Your best bet would be to traverse the object, create a vivified object for each object in the source and when you hit a leaf, i.e a non object value just assign it.

All of this is best explained with some code.

// for convenience here, make the autovivify function accept a starting object as well
function autovivify(obj = {}) {
   return new Proxy(obj, { ...

// copy from the source
function vivify(source) {
// isArray and isObject are simple utils
    const result = util.isArray(source) ? autovivify([]) : autovivify();
    for (const key in source) {
        if (util.isObject(source[key])) {
            result[key] = vivify(source[key])
        } else {
            result[key] = source[key]
        }
    }
    return result;
}

Now you can do stuff like

const vivified = vivify({ p1: { p2: [] } })
console.log(vivified) // { p1: { p2: [] } }
console.log(vivified.p1.p2) // []
vivified.p1.p3.p4.p5.p6 = 2 // create a new deep property assignment
console.log(vivified.p1.p3.p4.p5.p6) // 2

An important limitation/feature here is that if you once assign a value to a property, vivification will not kick in as intended. For example:

const v = autovivify();
v.p1.p2 = 2;
v.p1.p2.p3.p4 = 4;
> Uncaught TypeError: Cannot set property 'p4' of undefined

Overall vivification is a strange property to most non Perl developers that with a little proxy magic can be achieved in JavaScript as well. Use it wisely...

Java’s strange bit of syntax

Aleksandar Aleksandrov — Sat, 26 Dec 2020 00:35:21 +0000

Have you ever seen code like this ?

public int getLootBoxContents(int lootBoxIdx)[] {
    // TODO: get loot
    return null;
}

If you do not look carefully you might actually miss it 😏

“Wait, what are those [] doing at the end of the method declaration? You can not be returning null on an int, so the return type should be int[] right?"

Yeap, you are correct and I really hope you have not seen this syntax in production code. Now apart from this being a peace of trivia knowledge you can use to impress your equally as nerdy friends at the bar, the real question is why is this allowed? Everywhere we look, in every guideline we see, we would declare the method signature as

public int[] getLootBoxContents(int lootBoxIdx)

and not

public int getLootBoxContents(int lootBoxIdx)[]

Syntactically similar languages like C# don't allow it as well, so what gives?

If you see this code in the always handy IntelliJ it will give you a hint on it's origin:

C-style array declaration of the return type of method 'lootBoxContents()'

For those of you who have not written C code, in C (C++ as well) arrays are not first class citizens in the language, which means they can not be used as the return type of a function. What we do in C instead is return a pointer to the array like so:

int* getLootBoxContents(int lootBoxIdx)

and if we want to return a fixed size array, we use

int (&getLootBoxContents(int lootBoxIdx))[5] // each loot box must be an array of size 5

OK, the second one looks a lot similar to what we have and we know that Java has inter-op with C with the magical native keyword. Still this is pure Java, not some Java to C shenanigans, so why is the syntax allowed?

Let’s look at another example, that is more familiar to developers.

int[] array;
int array[];

The declarations on the two rows above are equivalent according to the java specification.

The precise array type depends on the bracket pairs that may appear as part of the type at the beginning of the method declaration, or after the method's formal parameter list, or both.
...
We do not recommend "mixed notation" in array variable declarations, where bracket pairs appear on both the type and in declarators; nor in method declarations, where bracket pairs appear both before and after the formal parameter list.

Or put simply, even the language writers advice us to always prefer int[] array.

Now the interesting bit from the same specification is:

Brackets are allowed in declarators as a nod to the tradition of C and C++.

And here we have our answer and it’s not simply a nod, as stated. If we go back in time to Java’s inception the dominant languages at that time were C and C++, so this syntax feature was also added to the language to help C/C++ developers in their transition to writing Java. Did it actually help with that … highly unlikely, but still it’s part of the language that will never go away and a nice peace of programing language history.