class sugar: static inheritance
Mark S. Miller
erights at google.com
Wed Jun 8 11:48:57 PDT 2011
On Wed, Jun 8, 2011 at 11:22 AM, Bob Nystrom <rnystrom at google.com> wrote:
> On Wed, Jun 8, 2011 at 9:55 AM, Brendan Eich <brendan at mozilla.com> wrote:
>> We can definitely leave protected out. My "seems inevitable" was in
>> response to Kam bringing it up via a question that I expect will be
>> frequently asked.
> I really hope we can. My interest in adding class syntax to JS was that I
> saw the same patterns being done again and again in the code I worked with
> and I wanted a lighter more declarative syntax for them. The proposal we
> have does a great job of that.
> So far, I very rarely see "protected" patterns in the code I work with, so
> adding that as language feature would buy me anything. It would just give me
> the ability to express something I don't care to express. Also, it we can
> get traits in JS.next.next, my hunch is that those two features won't play
> nice together.
> In C++ protected is used quite a bit, judging from Mozilla's codebase.
> I used to use it a lot in my C++ days too but I had a different mindset
> then. My C++ philosophy was "make sure no *can* break my class's contracts
> and encapsulation". When I moved over to JS I found that softening to "make
> it easy to not break the contracts and encapsulation but presume most of my
> users are not malicious". (The "private" stuff in the proposal that Mark is
> championing is great for when users actually *are* malicious.) From that
> angle, protected doesn't buy me much. It's not strong enough for security,
> and it's stronger than needed when we're all friends.
> - bob
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss