Oh oh oh, I got another one: refactoring... If both sides aren't equal, you'll never figure out what goes where in the new situation without too much trail and error.
EdB On Thu, Nov 7, 2013 at 6:49 PM, Erik de Bruin <[email protected]> wrote: > 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 -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
