kamkasravi at yahoo.com
Wed Nov 2 08:25:34 PDT 2011
Does object at name break encapsulation? One could mutate object at name for any instance of the class passed in via a parameter for example.
On Nov 2, 2011, at 8:01 AM, David Bruant <bruant.d at gmail.com> wrote:
> Le 02/11/2011 14:26, Jeremy Ashkenas a écrit :
>> (Full Disclosure: I'm still very opposed to const, private, and their object-lockdown friends, ....)
> Could you elaborate on this point?
> All object-lockdown I can think (non-configurability, non-writability, non-enumerability, private names, const variables, const classes) of is optional. Why are you against them?
> Regarding "const", it's an optional keyword basically telling the interpreter "hey, the value isn't suppose to change at runtime, please ensure it!". It prevents bugs of mistakenly redefining something that shouldn't be redefined. Why are you opposed to this?
> Regarding "private", I'm puzzled. Having private attributes in objects is necessary to implement encapsulation and get all the benefits of good object-oriented practices.
> A generation of JS programmers have used scope constructs and the "var" keyword to enable some privacy. I'm all in favor of providing a declarative support for what people have done for years anyway. What is wrong with "private"?
> Once again, all of this is optional, nothing forces you to use new features of the language. I will personnally never use multi-line strings, but I don't mind the feature being in the language.
> I was about to say "if you're unsatisfied, create a language which doesn't provide features you don't like, like Coffeescript", but... humm...
> So, why being against the introduction of features in the language?
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss