Where does the goog.reflect.objectProperty appear in the output? In the data stream?
On 1/16/20, 1:35 PM, "Harbs" <[email protected]> wrote: Amazing! > On Jan 16, 2020, at 10:59 PM, Josh Tynjala <[email protected]> wrote: > > Thank you, Harbs! Wrapping the variable name in a > goog.reflect.objectProperty() call works perfectly. This is exactly why I > started this thread, to see if anyone could suggest possible alternatives. > > Thankfully, we can keep the same simple data structure as before, and my > initial proposal with functions can be forgotten. In a release build, I can > see that goog.reflect.objectProperty() calls are replaced by a simple > string literal (containing the minified variable name), so we don't have to > worry about extra performance impact. > > -- > Josh Tynjala > Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C6989d0c95b5d446ca0a208d79acbef36%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148072995391870&sdata=c33xVrJb%2BPoqPWLgcvcpmyVjO8TYBKzJkNhz1NisDpw%3D&reserved=0> > > > On Wed, Jan 15, 2020 at 8:32 PM Harbs <[email protected]> wrote: > >> Sounds good! >> >> >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C6989d0c95b5d446ca0a208d79acbef36%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148072995391870&sdata=EqoLXGt8acxKifq31XQv%2F61ClzyLEvj%2Ft5OdyBmmTd8%3D&reserved=0 >> < >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C6989d0c95b5d446ca0a208d79acbef36%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148072995391870&sdata=EqoLXGt8acxKifq31XQv%2F61ClzyLEvj%2Ft5OdyBmmTd8%3D&reserved=0 >>> >> >> The function seems to be goog.reflect.objectProperty() >> >> I’m not sure exactly how it works though. >> >>> On Jan 16, 2020, at 1:37 AM, Greg Dove <[email protected]> wrote: >>> >>> actually just as another fyi, Harbs pointed out some intriguing goog >>> methods recently - I don't have an immediate reference to it sorry. One >> of >>> those seemed to allow for access to renamed names by wrapping the >> original >>> names in a 'magic' method that presumably GCC recognises (but presumably >>> returns the name unchanged in debug mode) >>> >>> >>> On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <[email protected]> wrote: >>> >>>> reflection data has similar stuff to support release mode get/set for >>>> public vars. >>>> >>>> I did not look at MXML startup assignments like this, but it sounds good >>>> to me. I don't know if it makes sense, but considering this is just >> startup >>>> assignments, could one function combine all of the startup assignments >> (in >>>> the same sequence as before)? >>>> >>>> >>>> On Thu, Jan 16, 2020 at 12:23 PM Josh Tynjala < >> [email protected]> >>>> wrote: >>>> >>>>> According to the commit linked below, the -warn-public-vars compiler >>>>> option >>>>> was added because setting a public var in MXML does not currently work >>>>> properly in a release build. >>>>> >>>>> >>>>> >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Fcommit%2Feed5882ba935870a98ba4fe8cbf499e5d8344f60&data=02%7C01%7Caharui%40adobe.com%7C6989d0c95b5d446ca0a208d79acbef36%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148072995391870&sdata=uQr3CVQajRPhW%2BQApIyV72o7PUziIHRKMtlNnI7eiiU%3D&reserved=0 >>>>> >>>>> In other words, this MXML code won't work if it's a public variable and >>>>> not >>>>> a setter: >>>>> >>>>> <Component publicVar="value"/> >>>>> >>>>> For reference, the compiler currently writes the name of the public >>>>> variable as a string to the generated JS, like this: >>>>> >>>>> var data = [ >>>>> Component, >>>>> 1, >>>>> 'publicVar', >>>>> true, >>>>> 'value' >>>>> ] >>>>> >>>>> At runtime, it interprets this array of properties, and basically runs >>>>> code >>>>> like this: >>>>> >>>>> comp['publicVar'] = 'value'; >>>>> >>>>> Since Closure compiler rewrites variable names during the minification >>>>> process, this code keeps using the original name, but other code in the >>>>> app >>>>> might start looking for a shorter variable name like "uB". This is the >>>>> failure that we're warning about. >>>>> >>>>> I propose updating the code generated by the compiler to something like >>>>> this instead: >>>>> >>>>> var data = [ >>>>> Component, >>>>> 1, >>>>> function(){ this.publicVar=true } >>>>> ] >>>>> >>>>> At runtime, the class that interprets MXML data will detect the >> function >>>>> and call it like this: >>>>> >>>>> func.apply(comp); >>>>> >>>>> Because this new code will no longer use a string, Closure can rewrite >> the >>>>> property name with its minified version, just like in other parts of >> the >>>>> app, and we'll no longer need to warn on declarations of public >> variables. >>>>> >>>>> I have a working prototype for primitive values, like String, Boolean, >> and >>>>> Number. Objects and Arrays follow a different path in the MXML data >>>>> interpreter, but I don't see why I wouldn't be able to handle those >> with a >>>>> similar approach. >>>>> >>>>> Thoughts? >>>>> >>>>> -- >>>>> Josh Tynjala >>>>> Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C6989d0c95b5d446ca0a208d79acbef36%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148072995391870&sdata=c33xVrJb%2BPoqPWLgcvcpmyVjO8TYBKzJkNhz1NisDpw%3D&reserved=0> >>>>> >>>> >> >>
