Do we need private accessors? about proposal-private-methods HOT 6 CLOSED

Private accessors can be useful for debugging reasons. If we have a private field and want to intercept it's modifications we can change it to a private getter / setter. If we don't have private accessors we would have to rename the variable to debug it.

from proposal-private-methods.

I don't really see the point of allowing private accessors, accessors in general seem to only really be useful to do one of a couple things:

1. Preventing data duplication while retaining an ergonomic API e.g.:

const person = {
    firstName: "Bob",
    lastName: "Smith",
    get fullName() {
        return this.firstName + this.lastName
    }
}

2. The Liskov substitution principle:

const yesImReallyADOMNodeTrustMe = {
    style: {
        set backgroundColor() {
            // Do some rendering to some fake DOM
        }
        ...
    }
    ...
}

The first reason might apply internally to the class, but the Liskov substitution principle obviously doesn't apply to private fields.

It could apply though if friend classes were possible e.g.:

// syntax for friend fields irrelevant
#x
#y

class Point2D {
    // syntax irrelevant
    outer #x
    outer #y
    constructor(x, y) {
        this.#x = x
        this.#y = y
    }
    
    transformBy(otherPoint) {
       return new Point2D(this.#x + otherPoint.#x, this.#y + otherPoint.#y)
}

class Point3D {
    outer #x
    #optimizedPoint
    constructor(x, y, z) {
        this.#optimizedPoint = engine3D.createPoint(x, y, z)
    }

    get #x() {
        return this.#optimizedPoint.getX()
    }
}

Given that friend private fields aren't part of the current proposal I don't really see any point in having private accessors unless there's some concrete examples of where ergonomics are really improved with it.

If they are desirable for friend classes then they can always be part of whatever proposal adds friend classes.

from proposal-private-methods.

At committee this seemed to come down pretty firmly on the side of "yes", if I remember correctly -
lots of people described use cases, often involving refactoring.

from proposal-private-methods.

I want to leave this open for future feedback for now. In some ways, it's easier to say "yes" than "no" to complexity.

As described in the unified class features explainer, one application would be for decorators which turn a private field into a private accessor, but we could delay private accessors for now until we also have decorator integration.

Another piece of motivation is orthogonality: Anything you can do publicly should be possible to do privately, so you don't have to think about, "I'm changing this between public and private; can I do that with this sort of class element?" The answer is always, yes.

from proposal-private-methods.

@littledan Regarding orthogonality the way private fields are spec-ed there's going to be things public fields can do that private ones necessarily can't. For example deletion (delete this.#x) and dynamic access (this[privateName]) can't be directly changed to some private field equivalent.

from proposal-private-methods.

We've concluded that we do want to add private accessors; see further motivation in #27.

from proposal-private-methods.