Responses also inline. Beyond this reply, I'm going to dip out and let others contribute their ideas for a bit... because I really need to focus on other things for now. If I go silent that is why.
On Thu, Sep 19, 2019 at 7:14 AM Alex Harui <[email protected]> wrote: > Responses inline. > > On 9/18/19, 11:53 AM, "Greg Dove" <[email protected]> wrote: > > Alex, the idea was to make the js output itself support the options, > without any need to manipulate any files at all. > Why would you not want to use goog defines? > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler%23define-type-description&data=02%7C01%7Caharui%40adobe.com%7C05e47962202a40946eac08d73c697d85%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637044296118065315&sdata=6RqR1nhJBOv9u0nAwGst325wXtHwWuKozGPZncE2FY0%3D&reserved=0 > > It seems like the easiest way and it leverages the strength of GCC. > > if (JSBuild.includeReflection) { > regular reflection data > } > > I haven’t spent a lot of time thinking about this, but I don't see how a > flag like JSBUild.includeReflection will drop reflection data for framework > classes unless we specify only certain classes as "framework classes" and > thus give only them that flag. > A single flag wouldn't. But with some careful planning a set of bit flags could be used to achieve reasonable selectability I think. Not something for most users, I agree. TBH I don't think most people will care about this level of detail for reflection, but I can see people definitely wanting to exclude it if they never use it in their app, and I'm sure some might want to really tune it at a granular level. Perhaps there is simply and on and off switch and the codeflow approach you mentioned can be introduced later for people who want the real stuff. > > redefining that JSBuild.includeReflection goog define to be false at > the > application build stage (which is for illustrative purposes here > only, and > would be true by default), eliminates it from all classes (that have > had it > included in the js output) in the release build, just like how > goog.DEBUG > works now. > > Having alternate swcs sounds complicated to me. It's different, but in > some > ways conceptually similar to monkey patching I guess (which works > also). > But it seems less desirable than being able to get everything you need > from > the one swc. > > OT: For the public vars stuff, that is not an issue for AMF > serialization. > Reflection classes do support the public var renaming and AMF works > fine > with the minimized names. I think the general issue with public vars is > that people can use regular dynamic access in actionscript, and that > should > work by default rather than be another hurdle. But of course it should > also > be able to be switched back to how it is now. > > public vars is not OT. It is the subject of this thread. I'm curious as > to how AMF supports the minified names. When an object comes in from the > server with a "name" property, how do you know it is now called "aa"? > > Good call. The Variabledefinition and AccessorDefinition classes both have getValue and setValue on-demand getter/setter creation. Support for public vars uses a single function that serves as a getter/setter internally which supports the renamed value in terms of getting/setting. Because all this is created on demand it does not add any overhead at startup, but it works like it should when it is needed via reflection. It's battle tested, works for AMF and Crux and I also use it in the manual-tests unit testing setup to run the same tests across debug and release builds. So to answer your question... it doesn't know or care what the renamed name is, the reflection class will map to it via its own gettter/setter approach. > The ideas for the granular stuff are interesting, but I think we need > to > go with things that are achievable in the near future, unless you > realistically think the code-flow stuff is something you can work on. > I don't think it's for me, but I believe I can do the stuff I already > mentioned. And I don't expect the approaches would be mutually > exclusive in > terms of evolving things in the future. > > My point is to be careful as to how much time we make folks spend trying > to understand our compiler options when we might want to do more > intelligent things instead. Having metadata or an interface drive the > output of public var is not complex like code-flow analysis and might avoid > folks having to learn some of these options or implement more options. Or > we might try inspecting GCC's string table to know what strings are being > used and prevent renaming based on that table. Code-flow is hard, but GCC > is using it and we might be able to leverage theirs. > > We already have all these compiler options, and I agree they could seem confusing to people unfamiliar with them. I consider that a first step is to migrate them to a setup that is more flexible without necessarily exploding them into many more options. I actually think Harbs 'bucket' approach addresses your first concern expressed here, even if you don't agree with what is in the buckets that were proposed.... would you not agree that this makes sense as a concept? My 2 cents, > -Alex > >
