On 12/19/12 2:18 PM, "Carol Frampton" <cfram...@adobe.com> wrote:
>
>
> On 12/19/12 5 :06PM, "Chema Balsas" <jbal...@gmail.com> wrote:
>
>>>
>>> The policy should be to not change valid and correct AS code in the SDK
>>> just
>>> because Falcon cannot compile it. There will be times when we will
>>> change
>>> the SDK code because Falcon is stricter than MXMLC, but I don't think
>>> these
>>> changes fall into that category.
>>
>>
>> I've already left some issues waiting for Gordon to comment on wether
>> they're Falcon bugs or not. I may have misjugded these. As I saw similar
>> code in place I assumed it was a safe change. I'll be reverting them soon.
>> Is it okay to wait to see if Gordon can confirm this as a Falcon bug, or
>> do
>> you prefer it to be reverted right away and then brought in later if not?
>
> Reverts are a pain in the neck so I'm fine with waiting for Gordon.
>
Chema, if you truly believe the language should not support the constructs
that are causing the problem, then you can wait for Gordon. But IMO, the
change you made in this checkin works around a bug in Falcon. It would be
better if you would create a JIRA ticket with a simpler test case. I think
the issue for DateTimeAxis and OLAPDG is that it overrides the setter but
not the getter and the code is trying to access the getter. I'm pretty sure
it is ok to override just the setter and not the getter.
In the other checkin, Falcon should not have issues with
whitespace/linebreaks so those lines should be valid. Again, filing JIRA
tickets with simple test cases or creating unit tests would be better.
Also, it may cause a bug to not use super.maxHorizontalScrollPosition in
AdvancedDataGrid.as. Falcon should not fail to compile super.someProperty
unless that propert is not defined on the ancestors.
If statements with assignments in subexpressions should still work. Please
file a JIRA ticket with a simple test case.
The only changes I saw that looked valid was the two changes to prevent
duplicate local property declaration.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
