Update: Changing Falcon to generate the coerce_a in the ternary clauses
allowed it to work for AIR. The code change is only in ternary expression
reduction so I think it won't hurt performance too much.
-Alex
On 10/1/13 10:09 PM, "Alex Harui" <aha...@adobe.com> wrote:
>So, I added code to add the coerce_a and it did not help. I get the same
>corrupted output.
>
>Here is the AS:
>package {
>public class foo {
>private var dict:Dictionary = new Dictionary();
>public function addInstance(instance:ISomeInterface):void
>{
> dict[instance.uid] = (instance.someBoolean ? new SomeClass(instance) :
>new SomeOtherClass(instance));
> ...
>}
>}
>
>//internal class
>class SomeClass{
>public function SomeClass(instance:ISomeInterface)
>{
>}
>//internal class
>class SomeOtherClass{
>public function SomeOtherClass(instance:ISomeInterface)
>{
>}
>
>
>
>Here is the ABC from MXMLC that works:
>
>
> getlocal0
> pushscope
> getlocal0
> getproperty private:dict
> getlocal1
> getproperty ISomeInterface:uid
> getlocal1
> getproperty ISomeInterface:someBoolean
> iffalse L0
>
> findpropstrict private:SomeClass
> getlocal1
> constructprop private:SomeClass (1)
> coerce_a
> jump L1
> L0: findpropstrict private:SomeOtherClass
> getlocal1
> constructprop private:SomeOtherClass (1)
> coerce_a
> L1: setproperty
> private,private,,http://adobe.com/AS3/2006/builtin:null
>
>Here is the ABC from Falcon that doesn't work:
>
> getlocal0
> pushscope
> getlex private:dict
> getlocal1
> getproperty ISomeInterface:uid
> getlocal1
> getproperty ISomeInterface:someBoolean
> iffalse L0
>
> findpropstrict private:SomeClass
> getlocal1
> constructprop private:SomeClass (1)
> jump L1
> L0: findpropstrict private:SomeOtherClass
> getlocal1
> constructprop private:SomeOtherClass (1)
> L1: coerce_a
> setproperty
>
> private,flash.events:EventDispatcher,Object,private,,http://adobe.com/AS3
>/
>2006/builtin:null
>
>I'm beginning to think this is an AIR bug since the Falcon ABC runs fine
>on Flash. I'm going to try to replicate the MXMLC's placement of coerce_a
>and see if that gets the code to work in AIR.
>
>
>Thanks,
>-Alex
>
>
>
>On 9/30/13 10:50 PM, "Alex Harui" <aha...@adobe.com> wrote:
>
>>There's no error, the Dictionary value appears be a Number instead of an
>>instance.
>>
>>Are you sure that Vector access doesn't come through this code? I think
>>I'll start by testing only for ANY_TYPE and adding a coerce_a instead of
>>calling coerce() which would also coerce to any destination type.
>>
>>Thanks for the advice,
>>-Alex
>>________________________________________
>>From: Darrell Loverin [darrell.love...@gmail.com]
>>Sent: Monday, September 30, 2013 6:11 PM
>>To: dev@flex.apache.org
>>Subject: Re: [FALCON] using coerce_a
>>
>>I generally agree. I don't think I'd try to do anything inside the
>>ternary
>>expression reduce.
>>
>>I'd look at the coerce() method in ABCGeneratingReducer to try to figure
>>out why it is not being called.
>>
>>
>>Question for Alex. What error are you seeing on AIR? A TypeError, a
>>ReferenceError?
>>
>>-Darrell
>>
>>
>>On Mon, Sep 30, 2013 at 8:00 PM, Gordon Smith <gosm...@adobe.com> wrote:
>>
>>> Thanks Darrell.
>>>
>>> Here are my answers to Alex's questions:
>>>
>>> > Should a complex assignment statement like the above know about the
>>> destination type as the clauses of the ternary statement are being
>>>reduced?
>>>
>>> No.
>>>
>>> > Is it safe to add a coerce_a before an assignment to a Dictionary?
>>>
>>> Yes.
>>>
>>> > If so, what would be the recommended way to determine the assignment
>>>is
>>> to a Dictionary?
>>>
>>> The compile-time type of foo[bar], where foo has any type (not just
>>> Dictionary), is type *. So I think it is OK to codegen coerce_a before
>>> assignment to any foo[bar] expression.
>>>
>>> Darrell, do you agree or disagree?
>>>
>>> - Gordon
>>>
>>>
>>> -----Original Message-----
>>> From: Darrell Loverin [mailto:darrell.love...@gmail.com]
>>> Sent: Monday, September 30, 2013 3:41 PM
>>> To: dev@flex.apache.org
>>> Subject: Re: [FALCON] using coerce_a
>>>
>>> coerce_a Operation
>>>
>>> Coerce a value to the any type.
>>>
>>> Format
>>>
>>> coerce_a
>>>
>>> Forms
>>>
>>> Stack
>>>
>>> ..., value => ..., value Description
>>>
>>> Indicates to the verifier that the value on the stack is of the any
>>>type
>>> (*). Does nothing to value.
>>>
>>>
>>> On Mon, Sep 30, 2013 at 6:03 PM, Gordon Smith <gosm...@adobe.com>
>>>wrote:
>>>
>>> > Can you remind me what the "a" in coerce_a means?
>>> >
>>> > - Gordon
>>> >
>>> > -----Original Message-----
>>> > From: Alex Harui [mailto:aha...@adobe.com]
>>> > Sent: Monday, September 30, 2013 2:43 PM
>>> > To: dev@flex.apache.org
>>> > Subject: [FALCON] using coerce_a
>>> >
>>> > Gordon, Darrell (mostly)
>>> >
>>> > My latest problem appears to be in assigning to a Dictionary. For
>>>the
>>> > following code:
>>> >
>>> > var dict:Dictionary = new Dictionary(); Var i:int; Dict["foo"] = (i
>>>==
>>> > 0 ? new SomeClass() : new SomeOtherClass());
>>> >
>>> > MXMLC generates a coerce_a after the constructProp for both SomeClass
>>> > and SomeOtherClass.
>>> > For some reason, FlashPlayer doesn't care if the coerce_a is missing,
>>> > but AIR seems to.
>>> >
>>> > The question is, should a complex assignment statement like the above
>>> > know about the destination type as the clauses of the ternary
>>> > statement are being reduced? And if so, how would we get that
>>>knowledge
>>> into the reducer.
>>> >
>>> > Alternatively, is it safe to add a coerce_a before an assignment to a
>>> > Dictionary? If so, what would be the recommended way to determine
>>>the
>>> > assignment is to a Dictionary?
>>> >
>>> > Thanks,
>>> > -Alex
>>> >
>>> >
>>>
>
