On Thu, Nov 7, 2013 at 8:56 AM, Erik de Bruin <e...@ixsoftware.nl> wrote:
> 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'? > +1 On the JS side, it should not cost us anything to have this kind of class inheritance hierarchy parity, right? Are we worried about performance in case of too much prototype chaining [1]? > > - 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 ;-) > Big +1 for this idea. If there is any chance I get to not write JavaScript directly, I want to make full use of it. Any chance you can publish your process for doing this? As an overly simple example, if I write a Chart component in AS, it would be so much easier if I go and replace the AS 'graphics' object to a JS 'canvas' or 'd3' object. Most other stuff should (hopefully) remain the same. > > 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 > > [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Inheritance_and_the_prototype_chain > > > On Thu, Nov 7, 2013 at 5:45 PM, Alex Harui <aha...@adobe.com> wrote: > > > > > > On 11/7/13 7:49 AM, "Erik de Bruin" <e...@ixsoftware.nl> 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 >
