Please do not use "#"

[babakness]

Two reasons taste and utility.

1. Taste: "Reason is the slave of passion" - Hume.

So I confess that to me, this is just straight up ugly. Can there be something other than the '#' character? Why not just a keyword

class {
  whatever x = 5
}

Where "whatever" is a clean word that anyone reading would understand and is also not painful to the eyes.

2. Utility. There could be a really awesome use of "#" in the future, lets not throw away that opportunity here.

[ljharb]

Please read the FAQ; you'll hopefully see why no keyword is feasible.

As for your personal taste; "ugly" is subjective, and many don't find it ugly.

[babakness]

Ok, subjectivity aside, # could have great potential for something in the future. Its a very assessable character. Right there above the middle finger.

This is an edge case concern. I can appreciate the need to have truly private attributes. Why not ### instead of # given the far reaching concerns and utility a single # can offer.

[babakness]

Consider, for example, that # in Scala is used for accessing nested classes. My point is that it is important to really consider the future of the language the ergonomics that are being forfeited. The FAQ is also full of opinions, for example, it is stated that this is confusing. I disagree, it is merely an implicit parameter rather than explicit as it is in python (self). Furthermore this is Javascript, it's a necessary learning curve.

I have to admit that having a this.bar inside of class and not a function is confusing in that prototypes are kind of masquerading as classes. Here, this isn't an implicit parameter, so yeah, its confusing.

This need for # is suspicious however. It feel that there is this supposed pressing need for the world that a keyword is just going to really slow things down. Why? Couldn't it be argued that a keyword could become # behind the scenes? So therefore # could really be anything, ###, or whatever.

A keyword is plausible. It is clearer, easier to read, easier to teach, and better to look than a misplaced # tattoo.

[ljharb]

A keyword used for declaration that is not also used for access won’t work (per the FAQ).

Do you have another single-character syntactic suggestion besides #? Multiple chars would just make this important feature (way more important than accessing nested classes, for example) less ergonomic.

[babakness]

Imagine if async/await was paired with symbols instead. Let's say #% and #$; so that one might write #%*function() { const foo = #$ bar() } or if the setters and getters were done using bizarre symbolic contraptions.

Of course keywords are better. A keyword for generators would have been even better. What follows is actual Perl code.

($l=join("",<>))=~s/.*\n/index($`,$&)>=$[||print$&/ge;

Let's stop making Javascript a write-only language. Adding these kinds of symbols is damaging to be sure. Perl went down this "developer ergonomics" rabbit hole. The aftermath of Perl attracted many to following wisdom

https://www.python.org/dev/peps/pep-0020/

# as proposed here is not easy to read, not easy to explain, not explicit, and inconsistent. In fact the problem the FAQ mentions about this are because it is implicit rather than explicit. The implicit behavior of this makes it difficult to teach. It is therefore ironic that # is suggested instead.

class Foo {
   const private bar = 5
   let private baz = 6
   method() {
     console.log( private bar)
     private baz = 7
     // private bar = 8 throws exception (const)
   }
}

What's wrong with that?

[ljharb]

It doesn’t allow you to access private values on other objects besides this.

I’d really suggest rereading the FAQ; all of your reasoning is sound, but seems to be missing some of the constraints.

[babakness]

I see this in the FAQ

this is already a source of enough confusion in JS; we'd prefer not to make it worse. Also, it's a major refactoring hazard: it would be surprising if this.x had different semantics from const thiz = this; thiz.x.

This also wouldn't allow accessing fields of objects other than this.

Those words are there just hanging around, no examples. Please explain and amend the FAQ to state the issue clearly with code so that one can reason about what exactly is the problem. Thanks.

[ljharb]

Here's an incredibly necessary and common example:

class Array {
  #arrayData = [];

  static isArray(obj) {
    if (!obj) { return; }
    try {
      return !!obj.#arrayData;
    } catch {
      return false;
    }
  }
}

Here's another:

let i;
class Foo {
  #id = i++;

  compare(other) {
    return other && this.#id === other.#id;
  }
}

[babakness]

function getFooClass () {
  let internalParameter = 'bookkeeping'
  let totalMembers = 0
  let prototype
  const Foo = function Foo() {
    prototype.totalMembers = ++totalMembers
    Object.defineProperty(this, 'totalMembers', {
      get: function() { return totalMembers },
      set: function() { throw 'read only' }
    });
  }
  prototype = Foo.prototype
  return Foo
}


const Foo = getFooClass()
const a = new Foo()
const b = new Foo()

a.totalMembers
// 2
b.totalMembers
// 2
Foo.prototype.totalMembers
// 2
a.totalMembers = 3
// read only

Is this roughly what you are communicating? Please clarify.

Note that internalParameter is not accessible at all from the outside and totalMembers is available from the outside to read only, but it can be changed from the inside. Also the entire thing about making Foo.prototype.totalMembers accessible can also be removed, obviously, so its just

function getFooClass () {
  let internalParameter = 'bookkeeping'
  let totalMembers = 0
  let prototype
  class Foo {
    constructor(){
      ++totalMembers
      Object.defineProperty(this, 'totalMembers', {
        get: function() { return totalMembers },
        set: function() { throw 'read only' }
      });  
    }
  }
  prototype = Foo.prototype
  return Foo
}

const Foo = getFooClass()
a = new Foo()
b = new Foo()

... or it can be made available to Foo but read only. Or not at all readable. Or we can return from getFooClass both the Foo class (prototype really) and a utility object that gives us stats, etc.

[ljharb]

Your "totalMembers" example is what would be a static private; my examples use a static method to read instance private fields off of multiple objects.

[babakness]

The above with the additional constraint that it would not be intended as an API... is that correct? I'm asking so I can clarify the problem to myself

[ljharb]

I'm not sure what you mean by "intended as an API"?

[babakness]

OK, I better understand now, thanks--I'll think it over for a while because there needs to be something better than wasting # for this purpose... not everyone even likes the class pattern let alone wants forfeit other potential utility of the symbol in the future.

Seriously if we are at a point where all other symbols are exhausted, extinguishing the last of the symbols from this endangered species is unwise. At least the # should be used where all programming styles would benefit. Consider for example the proposed |> operator.

https://github.com/tc39/proposal-pipeline-operator

Its great and all breed of programmers benefit from it. From different skill levels to different philosophies. And that's two characters while far more useful for day-to-day programming.

For now however, shouldn't there be a let or const declared to state if this can or can't be re-assigned? Seems more consistent.

[ljharb]

It’s a field, not a variable.

[babakness]

Here you go

const privateStuff = {}
const initPrivateStuff = function(instance) {
  privateStuff[instance.id] = {
    data: []
  }
}

class Foo {
  static isFoo(obj){
    if(obj && obj.id){
      return privateStuff[obj.id] != null ? true : false
    } else {
      return false
    }
  }
  constructor(){
    this.id = Symbol()
    initPrivateStuff(this)
  }
}

const foo = new Foo()
const bar = new Foo()

console.log(Foo.isFoo(bar))
//true
console.log(Foo.isFoo(foo))
//true

If I understand the issue correctly, please consider if your objections are more valuable than forfeiting # from scenarios that better benefit the community along with all other sound objections again # (lack of readability, inconsistency with the actual language, teachability, cryptic, etc.)