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
