IIRC, I've been able to make the compiler to not complain when having private and protected NS to the constructor, the player doesn't expect anything except public, so, the trick was to add an internal annotation on the class (not possible on the constructor itself) to keep that information and replace the constructor wit public to make FP happy, later in the compilation process, when examining the annotation, add the information to the class definition and later again report a problem if the code try to instantiate a protected / private class, I guess, it could work even for custom NS.
Note: the annotation is lost when compiling with -debug=false or -optimize=false Another option could have been to include in the generated constructor the byte code around the user one that I use in AS when I create an abstract or a private class as shown here https://gist.github.com/doublefx/b1173808e34ad35d8d40 Thoughts ? Frédéric THOMAS ---------------------------------------- > Date: Sat, 13 Jun 2015 12:23:16 -0400 > Subject: Re: Re : Re: Re : Re: AW: AW: AW: [FlexJS] IntelliJ Integration > From: teotigraphix...@gmail.com > To: dev@flex.apache.org > > On Sat, Jun 13, 2015 at 11:52 AM, Frédéric THOMAS <webdoubl...@hotmail.com> > wrote: > >> Yep, would like to see private / protected constructors, method >> overloading, generics and lambda in falcon to overwhelm any competitor :-) >> > > > I wish I got paid doing this because I would take 3 months of my life and > learn the low level of compiler theory and engineering and I could > implement it in the compiler. > > That is what sucks, the ActionScript language COULD compete with these > languages out today as a progressive language, but there is no money behind > it to drive innovation. > > >> >> I've been trying time ago for private / protected constructors using class >> annotation in the compiler, I wasn't far but lost all my job with my >> computer :-( and wasn't easy for me as I'm not a compiler guy. >> >> I guess the same principle could use for method overloading, not sure for >> generics but why not as at the end, it is only compile time checking and >> the info could be erase at runtime as done in Java. >> > > Can you show me examples of what you were doing? Start a new thread if you > do. > > Mike > > > >> >> Thoughts ? >> >> Frédéric THOMAS >> >> >> ---------------------------------------- >>> Date: Sat, 13 Jun 2015 11:40:22 -0400 >>> Subject: Re: Re : Re: Re : Re: AW: AW: AW: [FlexJS] IntelliJ Integration >>> From: teotigraphix...@gmail.com >>> To: dev@flex.apache.org >>> >>> On Sat, Jun 13, 2015 at 11:35 AM, Frédéric THOMAS < >> webdoubl...@hotmail.com> >>> wrote: >>> >>>> Btw, what happen when you compile JS.swc stuffs in AS ? >>>> >>> >>> >>> Yeah, the only reason for the JS.swc is code completion and compile API. >>> You know, just tricks the compiler into thinking JS DOM calls are >>> actionscript and does correct type checking. >>> >>> Basically think of the PLAINJS output type as a little "TypeScript" >>> compiler. Justa quick AST generation and AST walk to emit JS code, done. >> :) >>> >>> Mike >>> >>> >>> >>>> >>>> Frédéric THOMAS >>>> >>>> >>>> ---------------------------------------- >>>>> From: webdoubl...@hotmail.com >>>>> To: dev@flex.apache.org >>>>> Subject: RE: Re : Re: Re : Re: AW: AW: AW: [FlexJS] IntelliJ >> Integration >>>>> Date: Sat, 13 Jun 2015 16:31:32 +0100 >>>>> >>>>>> No, no more subclasses what I meant to say is if the output type is >> JS, >>>> the >>>>>> client compiler will automatically configure the FlexJS emitter based >> on >>>>>> the fact it wants to produce clean JS. >>>>> >>>>> I'm fine with that approach as the FLEXJS_DUAL output type re-invokes >>>> the compiler after the swf compilation to compile the JS with FLEXJS >> output >>>> type. >>>>> >>>>> Frédéric THOMAS >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> Date: Sat, 13 Jun 2015 11:27:03 -0400 >>>>>> Subject: Re: Re : Re: Re : Re: AW: AW: AW: [FlexJS] IntelliJ >> Integration >>>>>> From: teotigraphix...@gmail.com >>>>>> To: dev@flex.apache.org >>>>>> >>>>>> No, no more subclasses what I meant to say is if the output type is >> JS, >>>> the >>>>>> client compiler will automatically configure the FlexJS emitter based >> on >>>>>> the fact it wants to produce clean JS. >>>>>> >>>>>> Mike >>>>>> >>>>>> On Sat, Jun 13, 2015 at 11:25 AM, Michael Schmalle < >>>>>> teotigraphix...@gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Jun 13, 2015 at 11:20 AM, Frédéric THOMAS < >>>> webdoubl...@hotmail.com >>>>>>>> wrote: >>>>>>> >>>>>>>>> I really want to try the JS.swc in this new build. :) >>>>>>>> >>>>>>>> Oh yes, I don't want to miss that either, big up for you too Mike !! >>>>>>>> >>>>>>> >>>>>>> >>>>>>> I'm not kidding myself, there is still a huge amount of work to be >>>> done to >>>>>>> get it to work correctly based on externals that are more complicated >>>> then >>>>>>> the ones I did right now. I think I managed to get packages(js >>>> namespaces) >>>>>>> working but I really haven't tested them. >>>>>>> >>>>>>> On top of this, the FlexJS emitter needs a bunch of configuration >> added >>>>>>> through it's emitter stage (to not produce GCC comments, inherits >> etc). >>>>>>> >>>>>>> What will probably happen is there will just be a JS output type that >>>>>>> subclasses the FlexJS emitter and turns everything off, then it's >> not a >>>>>>> rats nest of config arguments. >>>>>>> >>>>>>> Mike >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Frédéric THOMAS >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------- >>>>>>>>> Date: Sat, 13 Jun 2015 11:06:59 -0400 >>>>>>>>> Subject: Re: Re : Re: Re : Re: AW: AW: AW: [FlexJS] IntelliJ >>>> Integration >>>>>>>>> From: teotigraphix...@gmail.com >>>>>>>>> To: dev@flex.apache.org >>>>>>>>> >>>>>>>>> Great job Fred, so this means we just need the FlexJS SDK and it >> will >>>>>>>> work >>>>>>>>> right? Do we still have to setup a library for code completion >> etc.? >>>>>>>>> >>>>>>>>> I really want to try the JS.swc in this new build. :) >>>>>>>>> >>>>>>>>> Mike >>>>>>>>> >>>>>>>>> On Sat, Jun 13, 2015 at 10:44 AM, Frédéric THOMAS < >>>>>>>> webdoubl...@hotmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Alex, >>>>>>>>>> >>>>>>>>>> I understand what you did but not sure I could reproduce, I wasn't >>>> that >>>>>>>>>> far in my experiment but I still miss the complete round trip >> logic >>>> of >>>>>>>>>> jBurg, I guess I would need to spend more time on it to get it >>>> better. >>>>>>>>>> >>>>>>>>>> Whatever, that's awesome, we can now compile and debug without any >>>>>>>>>> dependencies on the Flex SDK in IntelliJ :-) big up !! >>>>>>>>>> >>>>>>>>>> I will commit soon what I've done too. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Frédéric THOMAS >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ---------------------------------------- >>>>>>>>>>> From: aha...@adobe.com >>>>>>>>>>> To: dev@flex.apache.org >>>>>>>>>>> Subject: Re: Re : Re: Re : Re: AW: AW: AW: [FlexJS] IntelliJ >>>>>>>> Integration >>>>>>>>>>> Date: Fri, 12 Jun 2015 22:19:47 +0000 >>>>>>>>>>> >>>>>>>>>>> OK, I think I got it. Try my latest commit. >>>>>>>>>>> >>>>>>>>>>> -Alex >>>>>>>>>>> >>>>>>>>>>> On 6/12/15, 12:41 PM, "Alex Harui" <aha...@adobe.com> wrote: >>>>>>>>>>> >>>>>>>>>>>>OK, I will work on it. Thanks for trying, it is rather strange >>>> stuff. >>>>>>>>>>>> >>>>>>>>>>>>On 6/12/15, 9:16 AM, "Frédéric THOMAS" <webdoubl...@hotmail.com> >>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>>Hi Alex, >>>>>>>>>>>>> >>>>>>>>>>>>>Well, I've been trying to get why I always get a cost "not >>>> feasible" >>>>>>>> for >>>>>>>>>>>>>your function but I'm failing to understand the logic of jBurg, >>>> maybe >>>>>>>>>>>>>seing your solution will unligthen me but at the moment I'm >>>> totally >>>>>>>> in >>>>>>>>>>>>>the dark. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>>> >> >>
