I’m not sure that this increases function call overhead or code size. I suspect it will have the opposite effect.
Basically, to avoid function calls in MXML structure, we’re requiring getters and setters in every public member. That results in two function calls in every class instantiation per member. That’s whether or not it’s actually used in MXML. Theoretically, if MXML classes are instantiated my times (such as in an ItemRenderer), the function calls might have an effect, but I’m still skeptical that it would have a negative net effect on performance. Yes. Functions in JS are slower than getter access, but getters are also slower than direct property access. I suspect that property getters are used many more times in code than MXML resolution. [edit to the above — which is fastest depends on browsers and it’s totally non-conclusive. Simple fuinctions might even be fastest in some browser (hello Firefox) due to inlining. I’m including a number of jsperf links at the end of this message. Take a look…] It’s also worth noting that browser vendors are under pressure to make function calls as fast as possible due to the recent trend towards functional programming. My experience has been that avoiding public vars is a pain and we want to make developers’ lives easier and not harder. Without empirical evidence that function calls in MXML structure will have a bad net effect my preferences are as follows: 1. See if there’s some way we can keep a simple structure and use the goog.reflect functions. 2. Use function access in MXML to enable use of public vars. 3. Keep it the way it is. The only question I have is how this effects modules? Wouldn’t modules have problems with public vars too? I wonder if it makes sense to have two compilations of libraries; one that supports max minification, and another which supports modules. (unless it’s possible to deal with this at app compile time) Harbs https://jsperf.com/object-defineproperty-vs-definegetter-vs-normal/35 <https://jsperf.com/object-defineproperty-vs-definegetter-vs-normal/35> https://jsperf.com/312319sakd/2 <https://jsperf.com/312319sakd/2> https://jsperf.com/312319sakd <https://jsperf.com/312319sakd> https://jsperf.com/getter-performance <https://jsperf.com/getter-performance> > On Jan 16, 2020, at 8:31 AM, Alex Harui <[email protected]> wrote: > > 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] > <mailto:[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 >> >> <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 >> >> <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>
