We've been down this road before. I would rather warn folks to change their code so it will be as small and fast as possible. Others don't seem to care and would rather not change their code. The end-of-the-road for the "must mimic Flex" is that we will rarely read and write variables/properties directly. All access of Objects and dynamics will have to go through a runtime type checking that emulates Flash in case the object turns out to be XML or Proxy.
Go ahead and code it up, but please make it an option. In the framework, we should just suppress the warning where it won't be used in MXML. I will continue to advise the people I work with to make modifications to their code. -Alex On 1/15/20, 9:44 PM, "Greg Dove" <[email protected]> wrote: Am I misunderstanding or does this fix a usability issue with mxml and public vars? If it is fixing something that does not work, then presumably it only 'costs' for people who want that thing to work (public var assignments in mxml instances?) and not for others. That seems like the app-dev still has the 'choice' so long as they are aware of it and care. Or is there an alternative for the developer who wants that to work exactly like it does in Flex? If this does fix a usability issue, then I don't understand why it should always be 'smaller' (and possibly less reliable) that is the threshold for decision making. We presumably need to apply a balance that we can be sure represents what users actually want. 'We are trying to reduce function call overhead and reduce download size, not increase it.' It would be good to actually test that, function call overhead in js is much lower than what it was in swf, but perhaps this still would be slower I guess - perhaps not if all startup assignments were combined into one function. In terms of 'size', the assignment name would be renamed/minified and possibly avoid a string table entry, and the extra 'function(){' would be a very common sequence at gzip level I expect (it would still show up as extra in the js-release length but perhaps could be close to neutral or even smaller at gzip level). This idea sounds to be worth exploring to me. The goog.reflect methods also sound like they might possibly offer some other approaches as well though, if they provide another way to address the same issue. On Thu, Jan 16, 2020 at 5:42 PM Alex Harui <[email protected]> wrote: > Clever idea, but I don't like it. We are trying to reduce function call > overhead and reduce download size, not increase it. The reasons you are > getting a public var warning is so that the app-dev has control over which > members will have function call overhead. I don't think we should take that > away from the app-dev. > > Also, In many cases, you can just suppress the warning since you know the > members are not being accessed from MXML. > > My 2 cents, > -Alex > > > > On 1/15/20, 3: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%7Cff845c64c5ae4280b9f208d79a4728cd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637147502737629685&sdata=npJLZs0oDyWiVzlOCP1OxJKpLesAtDqrwx%2BygOVENXE%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%7Cff845c64c5ae4280b9f208d79a4728cd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637147502737629685&sdata=9TZ66rVPqQH1R7cMBHYtuKS18nQ7wtgE0Sn9PGujmPE%3D&reserved=0 > > > > >
