> Yes, BUT Falcon COMPC still needs an Object definition to compile! ;-) That
> is the sticker point here, you see my point?
Ah yes, I see your point, does it mean we should live without completion in IJ
for this extended definition ?
Btw, weird, it seems to be like that only for Object, For Array I can do
Array.isArray() with completion.
Frédéric THOMAS
----------------------------------------
> Date: Wed, 17 Jun 2015 11:20:29 -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 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
>>>>
>>>>
>>>>
>>
>>
