"Alex if you have a different view of how this should work, please let me
know."

Sorry I have been to long in the compiler. I see what is needed in the
framework code now. I will just use what is there. :)




On Fri, Sep 9, 2016 at 12:32 PM, Greg Dove <greg.d...@gmail.com> wrote:

> Actually I think the safest thing to do here would be to output the
> immediate base class, I *think* that should always work correctly. And that
> is all I need to follow the inheritance chain and collect the inherited
> members for the higher level TypeDefinition. Alex if you have a different
> view of how this should work, please let me know.
>
>
>
>
> On Fri, Sep 9, 2016 at 12:19 PM, Greg Dove <greg.d...@gmail.com> wrote:
>
>> Never mind, I think I don't need to do this output. It looks like I can
>> simply use constructor.superClass in js and go recursive. Please ignore.
>>
>>
>>
>> On Fri, Sep 9, 2016 at 12:07 PM, Greg Dove <greg.d...@gmail.com> wrote:
>>
>>> Alex this might be a question more for you, unless others are familiar
>>> with the topic.
>>>
>>> I am currently doing a bit more on reflection. Instead of outputting the
>>> fully resolved ancestral definition for each class, which would mean a lot
>>> of duplicated output across the inheritance chain, I assumed it would be
>>> best to resolve this at runtime (with caching) in the TypeDefinitions. So
>>> each TypeDefinition lookup would check its ancestors and add to its local
>>> collection of instance based members if they weren't already 'declaredBy'
>>> again (an override), and I envisaged caching the fully resolved
>>> TypeDefinition. This would get to a similar result to flash native
>>> describeType.
>>>
>>> so I am adding inheritsFrom into the output like so:
>>>
>>> MyInitialView.prototype.FLEXJS_REFLECTION_INFO = function () {
>>>   return {
>>>     inheritsFrom: function () {
>>>       return [ 'org.apache.flex.core.View',
>>> 'org.apache.flex.core.ViewBase', 'org.apache.flex.core.ContainerBase',
>>> 'org.apache.flex.core.UIBase', 'org.apache.flex.core.HTMLElementWrapper',
>>> 'flash.display.Sprite', 'flash.display.DisplayObjectContainer',
>>> 'flash.display.InteractiveObject', 'flash.display.DisplayObject',
>>> 'flash.events.EventDispatcher', 'Object' ] ;
>>>     },
>>>
>>> But it seems that the framework swc library only provides the flash
>>> version of the inheritance chain for this, because jx sees the
>>> flash.display.* classes in the loaded typedefinitions. Is there any way the
>>> compiler can load the definitions that were used when the js part of the
>>> swc was compiled for jx? I suspect not at the moment, but I'm just checking
>>> that I am not missing something obvious.....
>>>
>>>
>>>
>>
>

Reply via email to