Actually I wasn't sure whether the compiler eliminated the dead js code. But we know that it can.
I get the point about the 'swiss-army-knife' but I don't think that applies here, because I think this is more a 'standard tool'. I can only directly recall one Flex project in the last 6 years that did not require the swf crossdomain security model. Perhaps I have forgotten some, but I suspect that the world is becoming more interconnected, not less. I know there will definitely be some who don't need this, and I guess there are certain types of application that always will be single-domain. But unless I misunderstand, it sounds like this need might be more for the majority than the minority. The point about the GCC stuff though I think is a little contrasting to the PAYG philosphy elsewhere. "AFAIK, public APIs have @export and are kept around. Which will be a good thing in multi-module apps some day." It sounds like we are keeping a lot of code that could be optimized or automatically excluded because it will be a good thing "some day" (the day when we support module loading). That sounds like the opposite of PAYG to me, because many projects may not need 'module loading' (and we don't have this yet anyway). I'm just trying to throw a potentially different way of looking at this in here, because, in theory at least, the closure compiler should be able to make a whole bunch of stuff go away in the release build if it is not used (dead code elimination, DCE). In practice, I have not tried it with any sizeable codebase, but I know other typedLanguage-toJS compilers get the job done here, and I know that things like including reflection data or not are also choices included in the options for output in at least one other toJS compiler. If this can work properly then we could actually have our cake and eat it too. And yes the future might mean other things for modules, but perhaps there are ways to get that working even with the renaming (DCE maybe not so much, I agree). On Mon, Apr 10, 2017 at 8:32 PM, Justin Mclean <jus...@classsoftware.com> wrote: > Hi, > > > And the net result should be that code you didn't in your app, isn't in > your app. > > As Greg pointed out the compiler can removed unused JS code i.e. methods > that are not called. See for instance [1] for details. So in this case if > you don’t use it will not end up in the AS code (as it’s JS only) and will > not end up in production JS code. > > > So when you break stuff out into a bead, we want the net code size and > performance for > > someone not using the bead to be the same or better. > > In this case it is the same, if it was moved to a bead it would be worse > for people who needed it. Only by tiny amounts but that’s the point you’re > trying to make i.e. slow dead by a 1000 tiny additions, and as you say lots > of people will need CORS support. > > > It is certainly worth revisiting the code we've written to see if other > > stuff can be pulled out into beads, so thanks for reviewing HTTPService. > > It is one of the early classes and probably needs a review. Given the > > above, my responses are inline below. > > We should provide clear documentation on this, currently there is none? > Having our own code not following the same philosophy is a barrier for > people contributing. In most other Apache projects if someone submits a > patch that may not be “perfect” other committers will help to improve it. > Pull request welcome and all that. > > > Possibly. As long as the implementation for folks not using headers > would > > be smaller/faster. > > That is likely to be the case, but it will be slower for people who do use > headers. How do we determine what is the most common use case? Isn’t that > going to vary by use / customer so we going to end penalising someone no > matter which way we go. > > > Possibly, but I claim that nobody should go into production without > > supporting timeouts, so I would leave that baked in. > > So why does this not apply to the method I added? Every single project > I’ve worked on has made cross domain calls. It's very uncommon for web > applications to have their database, rest services, API calls on the same > domain and quite common to call 3rd party services. > > And I’m sure no one would go into production without supporting security > of some form. I’m concerned her that we are making security an optional > feature here and not having it supported by default. > > > Again, if you can find a way to refactor that out without making the > > HTTPService bigger/slower, then great. > > Anytime you place something in a bead it is going to be bigger and slower > for the people that need that functionality. It will be faster/smaller for > the others who don't. So again how do we determine what is the most common > use case? Do more people use AIR status code than don’t use them? I would > guess not in this case and it should be a bead but it’s just a guess. > > > Like Timeout, I claim that nobody should go into production without > > handling errors. So probably, the JS errors need to be handled right in > > HTTPService or HTTPServiceBase. > > So you're saying that HTTPService is where JS security errors should be > handled and not in a bead? > > Thanks, > Justin > > 1. https://developers.google.com/closure/compiler/docs/api-tutorial3
