On Jun 25, 2015 8:07 AM, "Alex Harui" <aha...@adobe.com> wrote:
>
>
>
> On 6/25/15, 8:02 AM, "Frédéric THOMAS" <webdoubl...@hotmail.com> wrote:
>
> >> Ah ok. That’s probably a bug. Not sure why, but the emitters currently
> >> initialize private members in the constructor. We discussed on some
> >>other
> >> thread a while back that this shouldn’t be necessary except for
> >>non-scalar
> >> initializers, so probably we should try to change this someday.
> >
> >Initializing methods in the constructor via myPrivateMethod = function()
> >{) will make it private but public instance methods not initialized in
> >the constructor won't be able to access it, public methods which aim to
> >access private methods need also to be declared in the contructor (eg.
> >"this.myPublicMethod = function() {return myPrivateMethod())")
>
> Really? I wasn’t aware of that. I didn’t think JS had any access
> protection at all.
>
> >
> >But do we need to replicate the AS3 NS behaviour in JS (public, private,
> >protected, custom NS) ?
> >
> >Has it been already discussed ?
> >
> >I'm not sure, my first answer would be no as the the developer will
> >develop in AS3 but if the code to be tested is the JS, I would answer
> >yes, we must reproduce what AS3 promises, the public, protected, private
> >and custom NS for classes and instances.
>
> I thought everything in JS was effectively public, that there was no
> access protection. But we are currently using Google Closure Compiler to
> minify all of the JS (and will probably always have a way for folks to
> choose to use it) and I think Erik says that proper use of @private helps
> the minifier.
>
> I’m not sure how we’d handle custom namespaces.
>
> -Alex
>
In Javascript we can create public, private and privileged variables,
using closures.
http://javascript.crockford.com/private.html
Thanks,
Om
