Well, I figured that if we have structural parity between the two frameworks, several things will happen:
- type checking becomes consistent: as soon as there is a different inheritance/implementation chain on the JS side, things go pear-shaped: how about 'myClass is Sprite'? - the frameworks will become easier to develop and maintain: build it on the AS side, and start the work on the JS side by copying the class structure. Or better yet, run the AS through the compiler and start with the JS output, that way you should be able to start with a reasonable functional JS class ;-) This is really cool, by the way. I put the entire AS framework through the compiler the other day and was amazed at how clean and nearly usable the JS output was... it got me thinking if we wouldn't want to just do the AS side (FlexJS style) and then see what's missing on the JS side (mostly flash.* classes, apparently). But that's for another time ;-) The other way around (only do what's really needed on either side) will get messy and obscure pretty soon, especially with the lack of a good code discovery/completion tool on the JS side. I got confused by the structural differences between the frameworks as it is right now, and we're only getting started... EdB On Thu, Nov 7, 2013 at 5:45 PM, Alex Harui <[email protected]> wrote: > > > On 11/7/13 7:49 AM, "Erik de Bruin" <[email protected]> wrote: > >>> was last built by MXMLC and not Falcon (or was built by Falcon without >>>the >>> -compiler.mxml.children-as-data flag). Every once in a while, FB will >>> suddenly re-build the SWF when you launch it. Not sure why. Om says it >>> happens every time for him. For me, I just run the external tool again >>> and it goes away. >> >>I figured as much, but the thing is, like Om, I haven't been able to >>run it at all :-( > Yeah. Will have to figure this out some day. The workflow shouldn't > require special launch configs if we can avoid it. > >>Since next on my list is an attempt to get the class structure on the >>JS side to match that on the AS side, it's not high priority for me, >>but it would be nice to have to occasionally run a test on both side >>of the aisle. > I'd like to make sure we're on the same page on this. Now that you've > provided interfaces on the JS side I can see that we should use them more, > but I don't think the set of superclasses and interfaces need to match > exactly. For example, we don't need a Sprite superclass in JS just > because there is one under the covers on the AS side. IMO, the only thing > that needs to match is the "API Surface", the set of public APIs. > > Your thoughts? > -Alex > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
