On 3/26/20, 11:14 AM, "Josh Tynjala" <[email protected]> wrote:
Snip...
I'm currently looking into a way to include a function with the MXML
descriptor that can be used to set the property, even if it has been
renamed. An evolution of what I proposed a couple of months ago. However, I
plan to keep both the string name and the value inside the descriptor so
that it does not affect your debugging approach.
A single property in the MXML descriptor looks like this now:
[
"someProperty",
true,
123.4
]
It might look something like this after my change:
[
"someProperty",
function(value) { this.someProperty = value; },
true,
123.4
]
If the function exists, it will be called like this (where host is the
component/object being created):
var func = descriptor[i];
func.call(host, value);
This will ensure that someProperty can be renamed, and all of the original
data is preserved for debugging.
I should be able to make the compiler smart enough to only include the
function where necessary (public vars) and omit it when not necessary
(public setters) to save on file size and make it PAYG. I would, of course,
also add a compiler option to include no functions in the descriptor (in
other words, keep the existing behavior).
Please consider the PAYG aspects of this approach. Without thinking about it
too much, it will at minimum make the MXMLDataInterpreter have to think harder
whether you use that capability or not.
It might be that we need to make sure there is an easy way to replace which
MXMLDataIntepreter gets used so that more sophisticated logic can be plugged in
if the app developer asks for it. And if we can do that, then it might just be
easier to have a test to see if the property exists before setting it and if it
doesn't check some sort of rename map.
Or, can we know which classes are having properties set via MXML and swap out
public vars for getter/setters?
HTH,
-Alex
