On 1/16/20, 2:24 PM, "Harbs" <[email protected]> wrote:
In other words reflection?
The reflection classes already deal with this IIUC.
You’re right that a simplistic serializer will not work, but for that they
wouldn’t be able to take advantage of the advanced minification anyway.
They might be able to use advanced optimization if we actually learn how to
control renaming in the Closure Compiler. Then we could prevent renaming of
public vars. We already prevent renaming of getters and setters.
The recommended solution should be to use reflection classes or disable the
advanced closure options. That seems reasonable for this edge case.
If we learn how to control renaming ,then we won't have to worry about edge
cases, nor will the users.
My 2 cents,
-Alex
> On Jan 17, 2020, at 12:19 AM, Alex Harui <[email protected]> wrote:
>
>
>
> On 1/16/20, 2:14 PM, "Harbs" <[email protected]> wrote:
>
> What do you mean? This is the solution recommended by the compiler.
>
> What are your concerns?
>
> Someone writes their own deserializer. It is going to do something like:
>
> Var listOfProperties = ["firstName", "lastName"];
> Function deserialize(inputStream:String, c:Class):Object
> {
> Var foo:Object = new class();
> Var values:Array = inputStream.split(",");
> Var i=0;
> For each (var name:String in listOfProperties)
> {
> foo[name] = values[i++];
> }
> }
>
> How will the compiler know to use goog.reflect.objectProperty here? IMO,
this change only solves the MXML problem but does not solve the other problems
the public var warning was put in for.
>
> I must be missing something. I'm out of time for the next 6 or 7 hours.
>
> -Alex
>
>> On Jan 17, 2020, at 12:11 AM, Alex Harui <[email protected]>
wrote:
>>
>> OK. I still think this is not the right solution. As I said public
vars are for more than MXML.
>
>
>
