On Jun 25, 2015 9:59 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>
> Yeah, but that is a very, very different design pattern and would require
> substantial work on the transpiler to make that output possible. It would
> also, I believe, be incompatible with the way the GCC optimizes (not
> minimize, mind you) the code, so that advantage would be lost as well.
>
> As our JS output is basically immutable, I think these discussions are
> missing the point and feel like trying to second guess the machine
> code/assembly that this JS basically is.
>
> When properly annotated, the GCC warns or throws an error if the code
seems
> to access 'privileged' members, but I'd guess that the AS compiler does
the
> same, so why worry?
>
> EdB
I think I am getting what you are trying to say. If you try to access a
private variable, you do that in AS, which the compiler catches. So
don't worry about exactly how the JS code is written, because that will
never happen during runtime. I think that is a fair point.
Thanks,
Om
>
>
>
> On Thu, Jun 25, 2015 at 5:45 PM, OmPrakash Muppirala <bigosma...@gmail.com
>
> wrote:
>
> > 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
> >
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
