Couple of responses inline.
On 9/18/19, 12:50 PM, "Greg Dove" <[email protected]> wrote:
<snip>
I can see people definitely wanting to
exclude it if they never use it in their app,
Originally, the REFLECTION_DATA was removed if you didn't use any Reflection
classes in the app. I hope that's still true. Although I'm not sure how many
real-world cases don't use Reflection somewhere...
>
> 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.
Minor nit: Sounds like getValue/setValue may not be PAYG.
> 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?
Don't know, don't care too much. I guess our customers will tell us. GCC has
big buckets like ADVANCED_OPTIMIZATIONS and SIMPLE_OPTIMIZATIONS that group
dozens of flags.
In my simple mind, people can better understand a single category (NONE,
SIMPLE, ADVANCED) better than concepts like Flash-compatibility vs size/speed.
Specific to this thread, if we did auto-generate getter/setters for public vars
if we found [ClassAlias] metadata, I wonder if that would allow us to get rid
of warn-public-vars entirely. Who would still get burned by it?
-Alex
