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
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 to have that feature.
>
> I wonder if that’s something we
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 to have that feature.
I wonder if that’s something we can add to Falcon?
On Nov 16, 2015, at 12:43 PM, Micha
On Mon, Nov 16, 2015 at 5:40 AM, OmPrakash Muppirala
wrote:
> Nope, you can still call new Singleton(null) and the compiler won't say
> anything :-)
> The 'enforcer' is required because of this loophole.
>
>
Yeah, you're right, to early in the morning.. :)
> Thanks,
> Om
>
> On Mon, Nov 16, 201
Nope, you can still call new Singleton(null) and the compiler won't say
anything :-)
The 'enforcer' is required because of this loophole.
Thanks,
Om
On Mon, Nov 16, 2015 at 2:36 AM, Michael Schmalle wrote:
> On Mon, Nov 16, 2015 at 4:14 AM, OmPrakash Muppirala >
> wrote:
>
> > Purely pedantic,
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
On Mon, Nov 16, 2015 at 4:14 AM, OmPrakash Muppirala
wrote:
> Purely pedantic, but the code does not do anything to 'enforce' the
> singleton-ness of the class.
>
The compiler won't even let you compile this code, so the != is just sauce
that never gets eaten. Since you have to pass an instance
Purely pedantic, but the code does not do anything to 'enforce' the
singleton-ness of the class.
It should actually be:
public function Singleton(e:SingletonEnforcer){
if(e != null)
{
trace("new instance of singleton created");
}
}
On Mon, Nov 16, 2015 at 12:54 AM, yishayw wrote:
> A
Actually the comment above 'class SingletonEnforcer' explains it.
package{
public class Singleton{
private static var _instance:Singleton=null;
public function Singleton(e:SingletonEnforcer){
trace("new instance of singleton created");
}
public stati
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-FalconJX-Inter
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
Hi Alex,
In my opinion internal classes are important and compiler should understand
them correctly.
One thing which always drive me crazy is that those classes are usually
placed in the same file with some other class. (That how it looks like in
ActionScript world).
I think SomeClass.as and SomeH
24 matches
Mail list logo
