Okay, cool. I just refactored a number of my changes into sub-emitters. - Josh
On Tue, Apr 5, 2016 at 3:36 PM, Michael Schmalle <[email protected]> wrote: > On Tue, Apr 5, 2016 at 6:29 PM, Josh Tynjala <[email protected]> > wrote: > > > Hey Mike, > > > > In my work on source maps, I've overridden a number of methods from > > ASEmitter that aren't currently in sub-emitters for JS. Should I go ahead > > and make new sub-emitters for those things? > > > > - Josh > > > > > Yeah, that is exactly what I am talking about. :) Then it's just delegation > and not inheritance. It also makes it very maintenance free down the road > if you want to switch something out. > > I know when I started the compiler it was all about template methods and > strategies for each emitter. > > The problem came when different outputs started getting add ed and goog > emitter started getting large that the inheritance really turned into > something I had not meant it to be. > > Just like the backends, I aimed at it all be configurable, so overriding > wouldn't need to happen, just change the strategy. > > Anyway, yes make the emitter, and I guess just create the instance where it > should be created for now. I know that was one thing I nver got to was > creating a factory for them and calling the factory where new is used right > now so it's still kind of half baked but doesn't mean it has to stay that > way. > > Mike > > > > > > > > > On Tue, Apr 5, 2016 at 3:19 PM, Michael Schmalle < > > [email protected]> > > wrote: > > > > > On Tue, Apr 5, 2016 at 5:36 PM, bill <[email protected]> wrote: > > > > > > > Here's our fork of the flex-falcon repo: > > > > > > > > https://github.com/Bee-Cave-Games/flex-falcon > > > > > > > > The last handful of commits reflect the changes Nimai mentioned > above. > > > > We're > > > > still learning our way around the code, so some of these things could > > > > likely > > > > be done in a simpler / better way. > > > > > > > > > > > > > > > Looks good to me! > > > > > > Everything can be simpler, last year I went through the main javascript > > > emitter and broke every thing out into sub emitters, MethodEmitter etc. > > > > > > I did that because it was starting to turn into a rats nest, I think > > there > > > is to much inheritance right now but that is more design. So I created > > > composites so you could easily do what you are doing right now, work in > > the > > > Class/Method emitters and feel pretty safe you are only changing that > > code. > > > > > > I can say with a pretty good certainty that is the way most of those > > > emitters behave right now. There are a few places where there is still > un > > > needed coupling and I think I still have those as TODOs. > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > View this message in context: > > > > > > > > > > http://apache-flex-development.2333347.n4.nabble.com/Starling-framework-compiled-to-JavaScript-tp52188p52192.html > > > > Sent from the Apache Flex Development mailing list archive at > > Nabble.com. > > > > > > > > > >
