Re: Proposal: Alternative public, private, static syntax and questions

2018-01-14 Thread Naveen Chawla 
Definitely TypeScript's system is better than the proposal. I often
publicize private variables and privatize public variables (In other
languages). The # scheme increases the effort to do so and increases the
chances of bugs being introduced in doing so. This is why I oppose the #
scheme.

I also don't accept the premises given in the justification, based on the
very fact that changing the access status of a variable would make it clash
with another variable, if this.x and this.#x were both allowed: I don't
accept therefore that allowing this would be desirable let alone necessary.

On Mon, 15 Jan 2018, 6:07 am Brandon Andrews, 
wrote:

> https://github.com/sirisian/ecmascript-class-member-modifiers
>
> Is this closer to what you think would be acceptable? Essentially
> C++/TypeScript kind of modifiers. Or does that still have issues?
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Alternative public, private, static syntax and questions

2018-01-14 Thread Brandon Andrews 
https://github.com/sirisian/ecmascript-class-member-modifiers

Is this closer to what you think would be acceptable? Essentially 
C++/TypeScript kind of modifiers. Or does that still have issues?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Alternative public, private, static syntax and questions

2018-01-12 Thread Isiah Meadows 
I'd have to disagree. There are ways to spec around this, and as long
as you make explicit what you're inheriting, it's not as hard as you
might think.
-

Isiah Meadows
m...@isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Fri, Jan 12, 2018 at 6:15 AM, Naveen Chawla <naveen.c...@gmail.com> wrote:
> Another problem with this.#myVar syntax is that it is not extensible to
> other access control definitions in future. For example "readonly" or
> "protected" etc.
>
> On Fri, 12 Jan 2018 at 05:12 Claude Petit <p...@webmail.us> wrote:
>>
>> I'm with you Isiah... Sorry, but all that to avoid "this." is laziness,
>> has no sense and add complexity to the language. Use a modern editor instead
>> of VI and you'll have auto-completion of that "so difficult to type" 4
>> letters word (this).
>>
>> -Original Message-
>> From: Isiah Meadows [mailto:isiahmead...@gmail.com]
>> Sent: Thursday, January 11, 2018 5:26 PM
>> To: Naveen Chawla <naveen.c...@gmail.com>
>> Cc: es-discuss@mozilla.org; Augusto Moura <augusto.borg...@gmail.com>;
>> Brandon Andrews <warcraftthre...@sbcglobal.net>
>> Subject: Re: Proposal: Alternative public, private, static syntax and
>> questions
>>
>> The proposal does a very poor job of explaining this, but `#foo` is a
>> shorthand for `this.#foo`, much like `{foo}` is a shorthand for `{foo:
>> foo}`. That kind of thing has precedent in other languages:
>> CoffeeScript uses `@foo` as a shorthand for `this.foo` (although it's not
>> private), and Ruby uses `@foo` as a shorthand for `self.foo` (which is
>> private by default). Most traditional strongly typed OO languages just let
>> you omit `this` and just reference the property as if it were a variable in
>> scope, without the sigil, and Ruby does as well for methods.
>>
>> It saves 5 characters in the most common case, accessing private
>> properties of the current instance.
>> -
>>
>> Isiah Meadows
>> m...@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 4:26 PM, Naveen Chawla <naveen.c...@gmail.com>
>> wrote:
>> > 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.c...@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, <isiahmead...@gmail.com>
>> >> wrote:
>> >>>
>> >>> Inline
>> >>>
>> >>> -
>> >>>
>> >>> Isiah Meadows
>> >>> m...@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
>> >>> <warcraftthre...@sbcglobal.net> wrote:
>> >>> >
>> >>> > That is a very useful document. I guess I haven't opened the
>> >>> > proposal in a while.
>> >>> >
>> >>&g

Re: Proposal: Alternative public, private, static syntax and questions

2018-01-12 Thread Naveen Chawla 
Another problem with this.#myVar syntax is that it is not extensible to
other access control definitions in future. For example "readonly" or
"protected" etc.

On Fri, 12 Jan 2018 at 05:12 Claude Petit <p...@webmail.us> wrote:

> I'm with you Isiah... Sorry, but all that to avoid "this." is laziness,
> has no sense and add complexity to the language. Use a modern editor
> instead of VI and you'll have auto-completion of that "so difficult to
> type" 4 letters word (this).
>
> -Original Message-
> From: Isiah Meadows [mailto:isiahmead...@gmail.com]
> Sent: Thursday, January 11, 2018 5:26 PM
> To: Naveen Chawla <naveen.c...@gmail.com>
> Cc: es-discuss@mozilla.org; Augusto Moura <augusto.borg...@gmail.com>;
> Brandon Andrews <warcraftthre...@sbcglobal.net>
> Subject: Re: Proposal: Alternative public, private, static syntax and
> questions
>
> The proposal does a very poor job of explaining this, but `#foo` is a
> shorthand for `this.#foo`, much like `{foo}` is a shorthand for `{foo:
> foo}`. That kind of thing has precedent in other languages:
> CoffeeScript uses `@foo` as a shorthand for `this.foo` (although it's not
> private), and Ruby uses `@foo` as a shorthand for `self.foo` (which is
> private by default). Most traditional strongly typed OO languages just let
> you omit `this` and just reference the property as if it were a variable in
> scope, without the sigil, and Ruby does as well for methods.
>
> It saves 5 characters in the most common case, accessing private
> properties of the current instance.
> -
>
> Isiah Meadows
> m...@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 4:26 PM, Naveen Chawla <naveen.c...@gmail.com>
> wrote:
> > 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.c...@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, <isiahmead...@gmail.com>
> >> wrote:
> >>>
> >>> Inline
> >>>
> >>> -
> >>>
> >>> Isiah Meadows
> >>> m...@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
> >>> <warcraftthre...@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

Re: Proposal: Alternative public, private, static syntax and questions

2018-01-11 Thread Logan Smyth 
The `#foo` shorthand part of the proposal was removed: https://github.com/
tc39/proposal-class-fields/issues/21

On Thu, Jan 11, 2018 at 2:26 PM, Isiah Meadows 
wrote:

> The proposal does a very poor job of explaining this, but `#foo` is a
> shorthand for `this.#foo`, much like `{foo}` is a shorthand for `{foo:
> foo}`. That kind of thing has precedent in other languages:
> CoffeeScript uses `@foo` as a shorthand for `this.foo` (although it's
> not private), and Ruby uses `@foo` as a shorthand for `self.foo`
> (which is private by default). Most traditional strongly typed OO
> languages just let you omit `this` and just reference the property as
> if it were a variable in scope, without the sigil, and Ruby does as
> well for methods.
>
> It saves 5 characters in the most common case, accessing private
> properties of the current instance.
> -
>
> Isiah Meadows
> m...@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 4:26 PM, Naveen Chawla 
> wrote:
> > 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, 
> 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, 
> >> wrote:
> >>>
> >>> Inline
> >>>
> >>> -
> >>>
> >>> Isiah Meadows
> >>> m...@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
> >>>  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

Re: Proposal: Alternative public, private, static syntax and questions

2018-01-11 Thread Isiah Meadows 
The proposal does a very poor job of explaining this, but `#foo` is a
shorthand for `this.#foo`, much like `{foo}` is a shorthand for `{foo:
foo}`. That kind of thing has precedent in other languages:
CoffeeScript uses `@foo` as a shorthand for `this.foo` (although it's
not private), and Ruby uses `@foo` as a shorthand for `self.foo`
(which is private by default). Most traditional strongly typed OO
languages just let you omit `this` and just reference the property as
if it were a variable in scope, without the sigil, and Ruby does as
well for methods.

It saves 5 characters in the most common case, accessing private
properties of the current instance.
-

Isiah Meadows
m...@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 4:26 PM, Naveen Chawla  wrote:
> 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,  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, 
>> wrote:
>>>
>>> Inline
>>>
>>> -
>>>
>>> Isiah Meadows
>>> m...@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
>>>  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).
>>> >

Re: Proposal: Alternative public, private, static syntax and questions

2018-01-11 Thread Naveen Chawla 
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,  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, 
> wrote:
>
>> Inline
>>
>> -
>>
>> Isiah Meadows
>> m...@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
>>  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@mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Alternative public, private, static syntax and questions

2018-01-11 Thread Naveen Chawla 
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,  wrote:

> Inline
>
> -
>
> Isiah Meadows
> m...@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
>  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@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Alternative public, private, static syntax and questions

2018-01-11 Thread Isiah Meadows 
Inline

-

Isiah Meadows
m...@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
 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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Alternative public, private, static syntax and questions

2018-01-11 Thread Brandon Andrews 
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).
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.

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?

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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Proposal: Alternative public, private, static syntax and questions

2018-01-11 Thread Augusto Moura 
See
https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md
for
clarification of the `#` sigil choice.


-- 
Augusto Moura
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss