On the parity issue: if we manage a proper introspection thing on the JS side, we should - in case of parity - be able to set up an automated way of checking both sides for completeness and sameness.
EdB On Thu, Nov 7, 2013 at 5:56 PM, Erik de Bruin <[email protected]> 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'? > > - 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 -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
