Is this really needed if we need a sigil

[Jordan-Hall]

Hi

I know they the topic about using private rather than sigil. But I want to say that's dead in the water because we all agree a sigil is needed as JavaScript Dynamic typed. But it lead me to believe that we should instead can we put an end to this proposal in the current state.

Can we not have some base decorators (https://github.com/tc39/proposal-decorators) and use @Private and @Protected to get this to work. I know @littledan would prefer to see a @ symbol rather than a # as it's ugly.

Example of someone's decorator: https://github.com/wojtkowiak/private-decorator. For me this would be a cleaner way and it would allow methods and classes to be private and protected without having to worry about anything. If this comes as default in JS then do we really need Sigil when we can mask it like a decorator.

Regards,
Jordan

[zenparsing]

You could perhaps imagine decorating a field definition with, say @private, but presumably you'd still access the field with this.x. And that leads back into all of the difficulties that have been previously enumerated with using this.x to access private state.

[zenparsing]

Regarding the linked decorator library, it has the following undesirable properties:

• Access implies runtime overhead costs
• Lookup traverses prototype chains
• It is not free of name-collision

[Jordan-Hall]

@zenparsing the example probably wasn't the best. But any access using # or not would require overhead cost. As for "It is not free of name-collision" I can't see this being an issue. If you consider local scope to class scope.

The problem I have with this sigil is soon we will run-out of symbols to use. For something is straight forward it would be better to force private with what we have or as private keyword.

I'm surprise nothing like this was mentioned when static methods was brought in.

[zenparsing]

But any access using # or not would require overhead cost.

I don't think this statement is true.

[bakkot]

One of the goals of this proposal is to provide encapsulation: that is, no information about private fields should be available outside of a class unless the class chooses to make it so (without directly inspecting the class's source). So, name conflicts do matter a great deal.

Here's an example:

class BaseLibrary {
}

class DerivedUser extends BaseLibrary {
  constructor(){ this.f = 1; }
}

Let's say BaseLibrary wants to change its internal implementation, in the process of which it introduces a new "private" field f:

class BaseLibrary {
  @privateMember
  f;
}

Suddenly DerivedUser's code is broken. This is not what we expect when we say that f is a private field.

I am reasonably sure that decorators cannot avoid name conflicts unless they provide an extremely surprising way of accessing private fields.

(Also, having implemented the current proposal I can say that access using a sigil doesn't involve comparable runtime costs. They can be resolved at parse time.)

[littledan]

To clarify, I don't have an opinion on the # vs @ issue. I think either symbol could be fine.

That linked decorator library notes in its documentation that it does not work in strict mode because it is based on the .caller property. Further, I share @bakkot and @zenparsing 's concerns.

[Jordan-Hall]

@littledan i Know that example was kinda poor of me. But my concerns with this proposal is we are running short of sigils symbols. we use @ for decorating and * for generators. What would be the sigil in the future for protected do we go with ##?

Cant we change the way we access private fields. rather than 'this.' Dont we use this:: or wasn't that ever approved?

[ljharb]

:: is currently part of the bind operator proposal, fwiw.

[Jordan-Hall]

@ljharb I thought it was. I just meant expect from looking at # which looks horrible, cant we do something around how we access the private field. Soon we will be our of sigil to use and will have to have a breaking change.

[littledan]

@Jordan-Hall I'd argue we don't need a separate protected feature; see https://github.com/tc39/proposal-private-fields/blob/master/DECORATORS.md for a way around it. I agree that we should figure out this issue up front; we can't add the feature and then remove it. However, I don't see a way that we can avoid using a sigil if we want private state. The proposal you have mentioned so far does not seem workable to me, but I'd be open to another one.

[Jordan-Hall]

@littledan saying I kinda agree that we will always have to use a sigil otherwise this. will always be accessible I'm going to close this. Like i stated before the # isn't a big deal I'm just more worried that any future feature we wont have a sigil left and we will have to think about a overhaul of the standards

[littledan]

Thinking about a possible overhaul that may be required later is definitely something we should do! If there are other sigil usages that come to mind for you, let's think about them and try to convince ourselves we're not headed for disaster.