My point is that if someone is using a swf-first workflow, they can’t just use
flex.* packages.
If we do some magic depending on whether it’s JS or AS, that might work.
On Apr 18, 2016, at 9:17 PM, Alex Harui <aha...@adobe.com> wrote:
>
>
> On 4/18/16, 11:01 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>>
>> On Apr 18, 2016, at 6:44 PM, Alex Harui <aha...@adobe.com> wrote:
>>
>>>
>>>
>>> On 4/18/16, 6:24 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>>
>>>> 2. Assuming we accept it, what should the package naming be? I think
>>>> there’s a strong case for leaving it as-is.
>>>
>>> IMO, I would rename "flash" to "flex". I'd like our FlexJS code to not
>>> mention Flash at all, regardless of whether there is some
>>> legal/copyright
>>> issue. It just helps make it clear that this stuff doesn't really use
>>> Flash, it helps us get out of the expectation that this code will
>>> somehow
>>> perfectly replicate what Flash does, and it helps users migrating to see
>>> what flash dependencies they have in their code.
>>>
>>> IMO, it isn't that hard to replace flash.*.* with flex.*.*, and I've
>>> been
>>> pondering a compile flag that automatically looks for a flex.*.* when it
>>> sees flash.*.*.
>>
>> Lizhi siad there’s a problem with changing the package so it can run
>> Starling.
>>
>> I’m not 100% sure what this means, but my understanding is that changing
>> the package names would require a lot of code changes to redirect to the
>> Flash packages in playerglobal.swc.
>> So, for example:
>> public class TextField extends InteractiveObject
>> {
>> }
>
> Maybe I have to go look at his code. My assumption is that he has a class
> called flash.text.TextField that emulates the Flash TextField in WebGL. I
> think we should rename that class to flex.text.TextField in our code base.
>
> Folks who are migrating code that references flash.text.TextField would
> have a choice. One is to manually change the "import
> flash.text.TextField" at the top of each file that uses it. That way they
> see which flash classes they are depending on that may not be fully
> implemented yet. Or we'll add a compiler flag so that every "import
> flash.text.TextField" causes the compiler to think you've written
> "flex.text.TextField" instead.
>
>> would have to become:
>> COMPILE::AS3{
>> public class TextField extends flash.text.TextField
>> {
>> }
>> }
>> COMPILE::JS{
>> public class TextField extends InteractiveObject
>> {
>> …
>> }
>> }
>>
>> I’m not sure if just making all the AS3 classes extend the Flash ones is
>> enough.
>
> I'm not sure I understand which classes you are talking about here.
>
>>
>>>
>>>>
>>>> 3. How should it be structured in the source? Should all the code go
>>>> into
>>>> a single “Flash” project? Should it be split into multiple projects
>>>> (possibly one for each of the flash top-level packages)?
>>>
>>> I haven't looked at the code, but if it is essentially the
>>> implementation
>>> behind playerglobal.swc, so it would be one SWC project in
>>> flex-asjs/frameworks/projects.
>>
>> Is there a performance/code size concern with putting everything in a
>> single SWC? Am I correct in assuming only the necessary code will be
>> compiled into JS/SWF?
>
> I expect that most apps are going to pull in a lot of this code anyway,
> but yes, only classes needed are included in the output.
>
> -Alex
