Do not parse command complete info unless accessed

[brianc]

This is probably a bit of a micro-optimization, but in my own codebases the number of times I access any of these properties is nearly zero. So, not parsing the command complete message unless there's a reason to do so (user wants to know about the command complete info) seems reasonable.

[sehrope]

Slight change in behavior of the props of the result with this as those fields won't appear in any default serialization for things like logging:

class Props {
    constructor() {
        this.foo = 123;
    }
}

class Getter {
    get foo() {
        return 123;
    }
}

function debug(obj) {
    console.log('%j', {
        keys: Object.keys(obj),
        obj,
    });
}

const p = new Props();
debug(p);
const g = new Getter();
debug(g);

$ node test.js 
{"keys":["foo"],"obj":{"foo":123}}
{"keys":[],"obj":{}}

I doubt it matters in most apps in practice but may be good to call it out in the changelog.

[brianc]

I doubt it matters in most apps in practice but may be good to call it out in the changelog.

hmm honestly it might not be worth changing if its gonna secretly break something esoteric on some deployed system. I didn't really notice much perf gain at all between the two implementations.

Thanks for your thoughts!! ❤️

[charmander]

Speaking of esoteric backwards compatibility needs: since the minimum Node version is 16, private class fields are fully supported. Could start using those instead of an underscore prefix for everything, to make future backwards compatibility easier to manage (since there’s no way user code can come to rely on private fields, whether it’s through direct access or stringification).

[brianc]

Could start using those instead of an underscore prefix for everything, to make future backwards compatibility easier to manage (since there’s no way user code can come to rely on private fields, whether it’s through direct access or stringification).

i love this idea. you're so awesome, ty!