Proposal: Alternative public, private, static syntax and questions

Naveen Chawla naveen.chwl at gmail.com
Thu Jan 11 21:26:33 UTC 2018


I hadn't read the proposal properly, but the thrust of my point is the
same, read remove/add `#` instead of "replace with this"

On Fri, 12 Jan 2018, 2:47 am Naveen Chawla, <naveen.chwl at gmail.com> wrote:

> Massive drawback of the # semantic: making a private variable public (a
> common transition when the usage of a class evolves) requires a lot more
> refactoring, since you have to remove every # for the variable across the
> class and replace it with `this`. Failing to do so in just 1 instance
> creates a bug. The same drawback applies for privatizing a public variable,
> in reverse.
>
> Besides which as an instance variable I want to learn `this` as the access
> prefix. I don't want to have to learn 2 different access prefixes, one for
> public and one for private. Access control in code only has one real
> material advantage: simplifying the public interface of a class by hiding
> factors that have no use from outside it. This is not big enough of an
> advantage to introduce a new access prefix, which can lead to a plethora of
> bugs due to confusion and/or publicization/privatization transitions during
> the evolution of one's system.
>
> On Fri, 12 Jan 2018, 1:22 am Isiah Meadows, <isiahmeadows at gmail.com>
> wrote:
>
>> Inline
>>
>> -----
>>
>> Isiah Meadows
>> me at isiahmeadows.com
>>
>> Looking for web consulting? Or a new website?
>> Send me an email and we can get started.
>> www.isiahmeadows.com
>>
>> On Thu, Jan 11, 2018 at 2:10 PM, Brandon Andrews
>> <warcraftthreeft at sbcglobal.net> wrote:
>> >
>> > That is a very useful document. I guess I haven't opened the proposal
>> in a while.
>> >
>> >
>> > He puts a lot of stress on preserving encapsulation where as I was
>> planning on relying on a type system to optionally provide that feature.
>> That is given a dynamically typed variable accessing privates would
>> probably be allowed. (Statically typed variables would detect and not allow
>> that kind of like a more strict usage).
>>
>> The issue with leveraging static typing is that JS has never been a
>> statically typed language. Also, private fields are generally
>> something you shouldn't need static types to detect - even without the
>> sigil, it *is* in fact possible to require something like `private
>> foo` as a declaration and alter property lookup within classes to
>> check for local private names (for class instances) before public
>> ones. (Decided to create a GH issue out of this:
>> https://github.com/tc39/proposal-class-fields/issues/69)
>>
>> > I think the inheritance and using private names as keys are decent
>> arguments. That said I'm personally not against allowing inherited classes
>> access to their base class private members though. That is private acting
>> like protected in C++ I think is fine for ECMAScript. Am I alone in being
>> fine with that behavior? I'm kind of leaning toward:
>> https://github.com/tc39/proposal-private-fields/issues/14#issuecomment-216348883
>> that syntax for a true private class scope variable.
>>
>> Note: not even Java allows subclasses to access superclasses' private
>> fields.
>>
>> >
>> > The key name conflict seems niche outside of key based data structures.
>> I wrote an ORM system before and just used a key called "internal" to hold
>> data in the past to get around a similar conflict. The # sounds like a
>> similar workaround when required but allows everything to not be hidden in
>> a nested object which is nice.
>> >
>> > Are "protected" class fields a thing in this discussion at all? Or is
>> the idea to use or implement a friend system later somehow?
>>
>> See https://github.com/tc39/proposal-decorators/issues/25.
>>
>> >
>> >
>> > With how I use Javascript currently, and the direction I want
>> ECMAScript to head - toward types - I don't particularly like the proposal
>> or necessarily support its goals toward creating an ideal encapsulation.
>> (Also I really dislike the syntax).
>> > _______________________________________________
>> > es-discuss mailing list
>> > es-discuss at mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180111/b8cbaa34/attachment-0001.html>


More information about the es-discuss mailing list