Seems to me like we could get a bunch of developers who are interested in the compiler to pile on and vote on an issue to show that it's important. I'd rather not have the compiler jump through hoops just to get one buggy IDE to give proper code hinting.
- Josh On Wed, Jun 17, 2015 at 8:34 AM, Michael Schmalle <teotigraphix...@gmail.com > wrote: > On Wed, Jun 17, 2015 at 11:25 AM, Frédéric THOMAS <webdoubl...@hotmail.com > > > wrote: > > > > Oh yeah one other thing Fred, EVERYTING needs to extend JSObject that > > > extends Object(in the externs def) for it to work correctly in IJ code > > > completion. Or else IJ will think the HTML class extends it's ECMA2 > > Object > > > and not JSObject. > > > > Yes, it is what I meant but EVERYTHING in JS.swc only, right ? > > > > Correct, it's just candy for the IDE. If somebody doesn't care about > Object.create() or myInstance.__proto__ then it really doesn't matter. > > But we cannot call this true JS until we allow natively these properties > and methods of ES3 and ES5 IMO. > > That is why eventually I am going to have to bite the bullet and implement > this. > > I got a busy 2 weeks coming up, I have a lot of remodeling for my mother in > law to do so I won't have as much time as I did these last 3 weeks, also > why I busted my ass, so people could have something to try out. > > Mike > > > > > > > Frédéric THOMAS > > > > > > ---------------------------------------- > > > Date: Wed, 17 Jun 2015 11:22:06 -0400 > > > Subject: Re: [FlaconJX] JS.swc design problems (was [FlexJS] IntelliJ > > Integration) > > > From: teotigraphix...@gmail.com > > > To: dev@flex.apache.org > > > > > > Oh yeah one other thing Fred, EVERYTING needs to extend JSObject that > > > extends Object(in the externs def) for it to work correctly in IJ code > > > completion. Or else IJ will think the HTML class extends it's ECMA2 > > Object > > > and not JSObject. > > > > > > Mike > > > > > > On Wed, Jun 17, 2015 at 11:20 AM, Michael Schmalle < > > > teotigraphix...@gmail.com> wrote: > > > > > >> > > >> > > >> On Wed, Jun 17, 2015 at 11:12 AM, Frédéric THOMAS < > > webdoubl...@hotmail.com > > >>> wrote: > > >> > > >>>> What Fred is saying, Have JSObject extend Object. Thus JSObject > would > > >>> have > > >>>> all ES3 and ES5 Object properties and methods, thus IJ would code > hint > > >>>> correctly > > >>> > > >>> I could be wrong but wrong but I would think it would work even > though > > >>> JSObject doesn't extend Object. > > >>> When you construct JS.swc parsing the definition files, when you meet > > the > > >>> Named Object class, just re-write it as JSObject anywhere and while > > >>> emitting the final JS file, re-write it as Object, that wouldn' do > the > > >>> trick ? > > >>> > > >> > > >> > > >> Yes, BUT Falcon COMPC still needs an Object definition to compile! ;-) > > >> That is the sticker point here, you see my point? > > >> > > >> Although, maybe I could just include an empty Object and then it would > > >> matter in IJ. > > >> > > >> Still the emitter will need to know about JSObject to transform it > back > > to > > >> Object during cross compile. > > >> > > >> Mike > > >> > > >> > > >> > > >>> > > >>>>> If Adobe adds something to Object in > > >>>>> playerglobal/airglobal will IJ pick it up? > > >>>>> > > >>>> > > >>>> I would bet it wouldn't. > > >>> > > >>> IJ would allow writing (without hints) and compile, due to the > dynamic > > >>> nature of Object. > > >>> > > >>> Frédéric THOMAS > > >>> > > >>> > > >>> ---------------------------------------- > > >>>> Date: Wed, 17 Jun 2015 10:51:09 -0400 > > >>>> Subject: Re: [FlaconJX] JS.swc design problems (was [FlexJS] > IntelliJ > > >>> Integration) > > >>>> From: teotigraphix...@gmail.com > > >>>> To: dev@flex.apache.org > > >>>> > > >>>> On Wed, Jun 17, 2015 at 10:29 AM, Alex Harui <aha...@adobe.com> > > wrote: > > >>>> > > >>>>> > > >>>>> > > >>>>> On 6/17/15, 7:20 AM, "Frédéric THOMAS" <webdoubl...@hotmail.com> > > >>> wrote: > > >>>>> > > >>>>>>> Fred; The point is, you would have to rename every package level > > >>> class > > >>>>>>>to > > >>>>>>> not get an ambiguous error in the IDE. > > >>>>>> > > >>>>>>Yes, but I guess it should be done for Object as there are no way > to > > >>> get > > >>>>>>it in IJ as it has a hardcoded definition, the JSObject option > seems > > >>> good > > >>>>>>to me, what about you ? > > >>>>> > > >>>>> Wouldn’t that mess up inheritance from everything that extends > > Object? > > >>>>> > > >>>> > > >>>> What Fred is saying, Have JSObject extend Object. Thus JSObject > would > > >>> have > > >>>> all ES3 and ES5 Object properties and methods, thus IJ would code > hint > > >>>> correctly because it's using it's builtin ECMA2 Object def and the > > >>> JSObject > > >>>> would extend from that. > > >>>> > > >>>> As I said, this si complicated because on my end it would not be cut > > and > > >>>> dry how I could do this, would add a huge amount of indirection in > the > > >>> code > > >>>> for the externs compiler and FlexJS emitter if we didn't have > > metadata. > > >>>> > > >>>> > > >>>> > > >>>>> Can I get a more detailed technical understanding of this issue? > How > > >>> does > > >>>>> IJ have a hard coded definition? > > >>>> > > >>>> > > >>>> It uses an ECMA2 file for ActionScript which looks like a compiled > > SWF I > > >>>> would guess. It does not use the Object definitions from > playerglobal > > >>> in a > > >>>> Flex/ActionScript project > > >>>> > > >>>> > > >>>> > > >>>>> Is this just for code completion in the > > >>>>> editor or is it compile time as well? > > >>>> > > >>>> > > >>>> It's code hinting. > > >>>> > > >>>> > > >>>> > > >>>>> I would think that if they are > > >>>>> calling our compiler that we could control this issue. Is this a > bug > > >>>>> worth filing against IJ? > > >>>> > > >>>> > > >>>> > > >>>> Well IJ and JetBrains really seem disinterested with ActionScript > > these > > >>>> days. > > >>>> > > >>>> > > >>>> > > >>>>> If Adobe adds something to Object in > > >>>>> playerglobal/airglobal will IJ pick it up? > > >>>>> > > >>>> > > >>>> I would bet it wouldn't. > > >>>> > > >>>> > > >>>> The ambiguous error is coming from MXMLC/JSC, its our compiler that > is > > >>>> barfing. > > >>>> > > >>>> > > >>>> Mike > > >>>> > > >>>> > > >>>>> > > >>>>> -Alex > > >>>>> > > >>>>> > > >>>>> > > >>> > > >>> > > >> > > >> > > > > >
