Why are #private fields not source-positional?

[trusktr]

I.e. why are they not scoped at the module level instead of at the class level?

This means we can't use #private fields along with class-factory mixins.

This works fine:

class Foo {
    #foo = 123
    test(other) {
      console.log(other.#foo)
    }
  }
}

class Cat extends Foo {}
class Dog extends Foo {}

const c = new Cat
c.test(new Dog) // logs 123.

Now we want to make the Foo class mixable (very beneficial for code organization):

function Foo(Base) {
  return class Foo extends Base {
    #foo = 123
    test(other) {
      console.log(other.#foo)
    }
  }
}

class Cat extends Foo(Object) {}
class Dog extends Foo(Object) {}

const c = new Cat
c.test(new Dog) // ERROR, Cannot read private member #foo from an object whose class did not declare it

Typescript playground example (maybe TS team overlooked this, because there is no type error).

[bakkot]

Because they're different classes. Just because two classes were created from the same source text does not mean they're the same class. It's the same reason that the last line is undefined in

function Foo(name) {
  let x = Symbol();
  return {
    [x]: name,
    name(){
      return this[x];
    },
  };
}

let one = Foo('one');
one.name(); // one

let two = Foo('two');
two.name.call(one); // undefined

Incidentally, https://github.com/tc39/proposal-private-declarations would make it easy to hoist the declaration out of the function, which would make it easy to make this pattern to work.

[trusktr]

Hello @bakkot! Thanks for answering, but you only explained what is happening. I know, that the private fields are scoped to each class instance.

I'm just wondering why wasn't it chosen to be module-scoped? For example, to describe it with WeakMap semantics, the WeakMaps would be at the top level of the module, not inside the mixin functions.

To explain it with Symbols, why was it not decided for it to be like the following:

let foo = Symbol(); // at the top level
function Foo(Base) {
  return class Foo extends Base {
    [foo] = 123
    test(other) {
       console.log(other[x])
    }
  }
}

?

That would be lot more practical for patterns like class-factory mixins. 😀

[bakkot]

If you're interested in the history, see #60, especially #60 (comment).

[trusktr]

So why not choose the design that would be more practical for most people (source-positional), and let those people who want particular security guarantees use WeakMap to do whatever they want? Why did we choose to do things opposite?

Now we have disparate and incompatible language features.

[ljharb]

"mixins" aren't a first-class language feature - otherwise class syntax would have some affordance for it.

The linked issue/comment explains some of the barriers to having private fields be reified as first-class values (Symbols or otherwise).

[trusktr]

The fact we can mix functions with classes was a feature of the language before #private fields was.

You always like to play on words only to be in an opposite position. Why do you do that? How can we make progress when you always do that?

The linked issue/comment explains some of the barriers

As I mentioned there, the barriers are for rare use cases, and people in those situations already have WeakMap to solve those rare needs.

It would be great not to make a language feature satisfy those rare use cases at the expense of practicality for majority use cases.

[trusktr]

I've been writing UI code, looking at other people's UI code, and working in Node.js applications for plenty of years now, and from this experience I believe source-positional private fields would have been a lot more practical and more beneficial for all the code bases I've ever worked in.

[ljharb]

The current private fields proposal will compose quite nicely with a future reification, which would cover your use cases.

The design you want would have resulted in no private fields feature at all, which would have prevented your use case as well as every other use case private fields supports. Nobody's disputing the value of "this feature plus one more", but you seem to be suggesting that adding private fields as-is - the foundation for the feature you want - is somehow indicative of use cases being ignored or somehow obstructed.

Private fields are analogous to a closed-over WeakMap per field. As such, absent the proposal, this code is roughly equivalent to your second example in the OP:

function Foo(Base) {
  const fooField = new WeakMap();
  return class Foo extends Base {
    constructor(...args) {
      super(...args);
      fooField[this] = 123;
    }

    test(other) {
      if (!fooField.has(other)) {
        throw new TypeError('Cannot read private member #foo from an object whose class did not declare it');
      }
      console.log(fooField.get(other));
    }
  }
}

class Cat extends Foo(Object) {}
class Dog extends Foo(Object) {}

const c = new Cat
c.test(new Dog) // ERROR, Cannot read private member #foo from an object whose class did not declare it

If you wanted both Cat and Dog to have access to the same WeakMap, you'd have to wrap them in a scope such that Foo, Cat, and Dog all shared lexical access to the same map. You can currently do this without private fields like so:

const { Foo, Dog, Cat } = (function () {
  const fooField = new WeakMap();

  function Foo(Base) {
    return class Foo extends Base {
      constructor(...args) {
        super(...args);
        fooField[this] = 123;
      }

      test(other) {
        if (!fooField.has(other)) {
          throw new TypeError('Cannot read private member #foo from an object whose class did not declare it');
        }
        console.log(fooField.get(other));
      }
    }
  }

  class Cat extends Foo(Object) {}
  class Dog extends Foo(Object) {}

  return { Foo, Dog, Cat };
}());

const c = new Cat
c.test(new Dog) // logs 123

Doing it with private fields is a bit more involved; writing it out here wouldn't help the discussion :-)

It would quite obviously be much more ergonomic to have reified private name values of some kind, and I hope we do get them someday. However, the lack of them now doesn't mean your use cases were "excluded" - it just means they aren't yet ergonomically satisfied.

[rdking]

Yeesh. Why does everyone choose the hard approach? There's a 1 line fix to the above code to give @trusktr what he wants.

function Foo(Base) {
  return class Foo extends Base {
    #foo = 123
    test(other) {
      console.log(other.#foo)
    }
  }
}

var FooObj = Foo(Object);
class Cat extends FooObj {};
class Dog extends FooObj {};

const c = new Cat
c.test(new Dog) //logs 123

The whole and sole of the problem is that each call to Foo() generated a new instance of the class definition. So each base class became distinct despite having the exact same shape. There are exactly 2 generic solutions to this. The first is the solution above. The second is to alter Foo to add in memoization so that it is a pure function.

[ljharb]

@rdking ha, thanks. I avoid mixin patterns, so your better approach didn’t occur to me.

[rdking]

@ljharb Np. Thing is, I don't use mixins either. I tried them back in the early ES5 days, but grew to hate them quickly. What's more, the so-called "mixin" approach above is more akin to templates or generics in other class-supporting languages. As for things being source positional, in my experience, if you want things to be source positional but they're not, there's usually another approach that will get you what you want.

[trusktr]

@rdking @ljharb I know I can do what I want with WeakMaps. I just feel that people with more obscure cases can also do the more obscure things with WeakMaps while most other people can just have source-positional simplicity.

I'm not familiar: what does `"future reification" and "reified private name values" mean?

@rdking I know about the approach you suggested, but that only work in that case. This doesn't:

function Foo(Base) {
  return class Foo extends Base {
    #foo = 123
    test(other) {
      console.log(other.#foo)
    }
  }
}

class One { ... }
class Two { ... }

class Cat extends Foo(One) {};
class Dog extends Foo(Two) {};

const c = new Cat
c.test(new Dog) // Error

@ljharb To show what I mean by source positional, only Foo's scope needs to have it, and we don't need to wrap all the classes:

const { Foo } = (function () {
  // suppose this is module scope

  const fooField = new WeakMap();

  function Foo(Base) {
    return class Foo extends Base {
      constructor(...args) {
        super(...args);
        fooField.set(this, 123);
      }

      test(other) {
        if (!fooField.has(other)) {
          throw new TypeError('Cannot read private member #foo from an object whose class did not declare it');
        }
        console.log(fooField.get(other));
      }
    }
  }

  return { Foo };
}());

class One {}
class Two {}

class Cat extends Foo(One) {}
class Dog extends Foo(Two) {}

const c = new Cat
c.test(new Dog) // logs 123, yay.

I'm curious about the "reified private name" idea, as I'm not sure what that means.

[trusktr]

Oh, I forgot to say: I don't see why elevating private fields to module scope means we can't ship them. It merely swaps the use cases that the feature is available for to those where it currently isn't available (f.e. mixins) which would benefit more people. It is always possible to add a new feature with the per-class privacy later too, to satisfy more unique and rare cases.