I can certainly see that certain "higher-level" components might be able to have the same structure and have the JS side generated by the compiler. But it seems to me that at some point,you need your platform abstraction layer and what happens underneath it will vary.
Are you really suggesting creating Sprite->InteractiveObject->DisplayObject on the JS side? How would you do it for the Button that wraps a Jquery or Dojo button? Would you really want to wrap JS accessibility in something that looks like accImpl or vice-versa? I know you "can" do it, but I would want each platform's implementations to be optimal, otherwise we are trying to emulate FP in the browser or vice versa, neither of which I think will be optimal. So, a tool that compares the API surface of an AS and JS class would be good, but I'm not sure it has to check base class ancestry and maybe certain interfaces can be marked as exceptions? -Alex On 11/7/13 11:38 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >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 <e...@ixsoftware.nl> 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 <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'? >>> >>> - 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 <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 >> >> >> >> -- >> 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
