On 11/16/15, 2:54 PM, "Michael Schmalle" wrote:
>On Mon, Nov 16, 2015 at 5:44 PM, Alex Harui wrote:
>
>>
>>
>> On 11/16/15, 2:04 PM, "Michael Schmalle"
>> wrote:
>>
>> >Is there some one else working on the compiler code other than you
>>Alex?
>>
>> Josh has made a few changes, but lately I t
On Mon, Nov 16, 2015 at 5:44 PM, Alex Harui wrote:
>
>
> On 11/16/15, 2:04 PM, "Michael Schmalle"
> wrote:
>
> >Is there some one else working on the compiler code other than you Alex?
>
> Josh has made a few changes, but lately I think I’m the main person. The
> log will show you.
>
> -Alex
>
On 11/16/15, 2:04 PM, "Michael Schmalle" wrote:
>Is there some one else working on the compiler code other than you Alex?
Josh has made a few changes, but lately I think I’m the main person. The
log will show you.
-Alex
On Mon, Nov 16, 2015 at 4:20 PM, Alex Harui wrote:
> Looks like the work would be:
>
> 1) add the wrapping function
> 2) change all method and property output to not include the package.
>
> Is it worth it just to try to get better privacy? I think just adding an
> inner class would be less work
Yeah, an inner class sounds like an acceptable approach. I don't think we
absolutely need to enforce this privacy on the JavaScript side. As long as
the ActionScript compiler won't let you use the inner class elsewhere,
that's fine.
I would say that adding some kind of prefix or something to the i
Looks like the work would be:
1) add the wrapping function
2) change all method and property output to not include the package.
Is it worth it just to try to get better privacy? I think just adding an
inner class would be less work for me. Some other volunteer could make
your proposed change la
All members assigned to the prototype would automatically be available.
You'd use pretty much the same syntax, but you wouldn't need to reference
the full package name for each member:
some.package.SomeClass = (function()
{
var SomeClass = function(){};
SomeClass.prototype.someMethod = fun
On Mon, Nov 16, 2015 at 11:28 AM, Alex Harui wrote:
>
>
> On 11/16/15, 2:38 AM, "Michael Schmalle"
> wrote:
>
> >It's important. You need to figure out how to do it in JS first, then bend
> >the compiler to your will. :)
> >
> >In a SWF decompile, these are labeled private class.
>
> OK. Well A
On 11/16/15, 10:36 AM, "Josh Tynjala" wrote:
>The Immediately-Invoked Function Expression (IIFE) pattern could be used
>to
>create private classes.
>
>some.package.SomeClass = (function()
>{
>var SomeHelperClass = function(){};
>
>var SomeClass = function(){};
>
>return SomeClass;
>
The Immediately-Invoked Function Expression (IIFE) pattern could be used to
create private classes.
some.package.SomeClass = (function()
{
var SomeHelperClass = function(){};
var SomeClass = function(){};
return SomeClass;
})();
SomeHelperClass will only be accessible inside the (fu
On 11/16/15, 2:38 AM, "Michael Schmalle" wrote:
>It's important. You need to figure out how to do it in JS first, then bend
>the compiler to your will. :)
>
>In a SWF decompile, these are labeled private class.
OK. Well AFAIK, there is no such thing as private classes in JS. One
thought I ha
On 11/16/15, 3:22 AM, "Michael Schmalle" wrote:
>On Mon, Nov 16, 2015 at 6:07 AM, Harbs wrote:
>
>> It would actually be very nice if there was some way to (optionally)
>> prevent null being passed into constructors and function calls. There
>>has
>> been more than once that I would have liked
t;>>
> >>>>> package{
> >>>>>public class Singleton{
> >>>>>private static var _instance:Singleton=null;
> >>>>>public function Singleton(e:SingletonEnforcer){
> >>>>>trace("new instance of singleton created");
> >>>>>}
> >>>>>public static function getInstance():Singleton{
> >>>>>if(_instance==null){
> >>>>>_instance=new Singleton(new SingletonEnforcer());
> >>>>>}
> >>>>>return _instance;
> >>>>>}
> >>>>>}
> >>>>> }
> >>>>> //I’m outside the package so I can only be accessed internally
> >>>>> class SingletonEnforcer{
> >>>>> //nothing else required here
> >>>>> }
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> View this message in context:
> >>>>>
> >>>>
> >>>
> >>
> http://apache-flex-development.247.n4.nabble.com/FlexJS-FalconJX-Internal-Classes-tp50091p50102.html
> >>>>> Sent from the Apache Flex Development mailing list archive at
> >>> Nabble.com.
> >>>>>
> >>>>
> >>>
> >>
>
>
t;>private static var _instance:Singleton=null;
>>>>>public function Singleton(e:SingletonEnforcer){
>>>>>trace("new instance of singleton created");
>>>>>}
>>>>>public static funct
;new instance of singleton created");
> > > > }
> > > > public static function getInstance():Singleton{
> > > > if(_instance==null){
> > > > _instance=new Singleton(new SingletonEnforcer());
> > > >
ngleton{
> > > if(_instance==null){
> > > _instance=new Singleton(new SingletonEnforcer());
> > > }
> > > return _instance;
> > > }
> > > }
> > > }
> > > //I’m o
It's important. You need to figure out how to do it in JS first, then bend
the compiler to your will. :)
In a SWF decompile, these are labeled private class.
Mike
On Mon, Nov 16, 2015 at 2:53 AM, Alex Harui wrote:
> Hi,
>
> Every once in a while, the framework code uses an “internal class”. A
ton(new SingletonEnforcer());
> > }
> > return _instance;
> > }
> > }
> > }
> > //I’m outside the package so I can only be accessed internally
> > class SingletonEnforcer{
> > //nothing else required here
> > }
&
t; }
> }
> //I’m outside the package so I can only be accessed internally
> class SingletonEnforcer{
> //nothing else required here
> }
>
>
>
> --
> View this message in context:
> http://apache-flex-development.247.n4.nabble.com/FlexJS-FalconJX-Internal-Classes-tp50091p50102.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
nEnforcer{
//nothing else required here
}
--
View this message in context:
http://apache-flex-development.2333347.n4.nabble.com/FlexJS-FalconJX-Internal-Classes-tp50091p50102.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
It ensures you can’t instantiate your singleton outside the singleton class.
On Nov 16, 2015, at 10:50 AM, yishayw wrote:
> Not sure why...
I've seen them used in Singleton implementations. Not sure why...
See here
http://stackoverflow.com/questions/10233868/why-there-are-no-private-constructors-in-as3-version-of-singleton
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/FlexJS-Fal
Yes. That’s bad for two reasons:
1. You could end up with conflicts between two different packages. (unless I’m
misunderstanding you)
2. Polluting the global object is really frowned on. We should have as few
globals as possible.
I’m not sure what the internal classes should become though.
On N
SomeHelperClass.as - should be in a separate class
- it is a better organization.
Just my two cents on that.
Piotr
-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/FlexJS-FalconJX-Internal-Classes-tp50091p50096
Hi,
Every once in a while, the framework code uses an “internal class”. An
examples would look like:
package some.package
{
public class SomeClass
{
}
}
class SomeHelperClass
{
}
SomeHelperClass is an “internal class”. In JS, SomeHelperClass gets
defined on the global object. I’m wonde
25 matches
Mail list logo
