Interesting scenarios. I would not have thought of that.
If we could figure out how to strip the function call and leave the parameter,
the compiler would strip out the contents if it could be safely removed.
So trace(“something”) would become “something” which is en empty statement and
would be stripped out.
Of course, I have no idea how to go about doing that… ;-)
Harbs
> On Jul 12, 2017, at 4:32 PM, Josh Tynjala <joshtynj...@gmail.com> wrote:
>
> Probably the same with function calls too:
>
> trace(someFunction());
>
> They wanted this to remain:
>
> someFunction();
>
> - Josh
>
> On Wed, Jul 12, 2017 at 6:22 AM, Josh Tynjala <joshtynj...@gmail.com> wrote:
>
>> One thing to keep in mind with stripping out trace() calls is that some
>> developers expect any modifications to variables that happen inside the
>> arguments to remain. I remember a while back someone at Adobe mentioning
>> that people complained when something like this was completely stripped out:
>>
>> trace(doSomething++);
>>
>> Because they expected this part to remain:
>>
>> doSomething++;
>>
>> - Josh
>>
>> On Wed, Jul 12, 2017 at 12:24 AM, Harbs <harbs.li...@gmail.com> wrote:
>>
>>> My bad. It does in fact compile down to this:
>>>
>>> function uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apach
>>> e.flex.utils.Language.trace',uM);
>>>
>>> So trace does not actually do anything. Great! :-)
>>>
>>> However, it’s still being called by the client code. (It just does
>>> nothing.) Not super important, but it would be nice if at some point we can
>>> figure out if there’s a way to strip out the calls completely.
>>>
>>>> On Jul 12, 2017, at 10:07 AM, Harbs <harbs.li...@gmail.com> wrote:
>>>>
>>>> Oof. I think I’m still waking up. ;-)
>>>>
>>>> I did not realize what I was looking at with the goog.DEBUG. My
>>> recollection is that trace statements are still being used in the release,
>>> but I’ll double check that.
>>>>
>>>>> On Jul 12, 2017, at 9:56 AM, Alex Harui <aha...@adobe.com.INVALID>
>>> wrote:
>>>>>
>>>>> Well, the goal of using goog.DEBUG in Language.as trace() was to
>>> convince
>>>>> GCC to eliminate trace(). I haven't checked whether it is working or
>>> not.
>>>>> Requiring everyone to use goog.DEBUG around trace statements sounds
>>> like
>>>>> a pain. Probably better to teach the publisher to remove it if GCC
>>> can't
>>>>> be taught to do it. We visit almost every line of the JS output in the
>>>>> publishers right now.
>>>>>
>>>>> My 2 cents,
>>>>> -Alex
>>>>>
>>>>> On 7/11/17, 11:47 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>> On Jul 12, 2017, at 8:20 AM, Alex Harui <aha...@adobe.com.INVALID>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Again, though, I think this optimization isn't urgent.
>>>>>>
>>>>>> I completely agree. That’s why I have not been bringing this up
>>> despite
>>>>>> it being on my mind. When the discussion came up, I couldn’t help but
>>>>>> join. ;-)
>>>>>>
>>>>>>
>>>>>>> goog.DEBUG is already being used in Language.as.
>>>>>>
>>>>>> Thanks! I hadn’t noticed. I was missing an import of of goog.DEBUG in
>>>>>> COMPILE::JS I’m guessing the imports of goog.bind and goog.global was
>>>>>> enough to make goog.DEBUG visible to the compiler in Language.as.
>>>>>>
>>>>>> Once we’re on this topic, there’s something that I had wanted to
>>> bring up
>>>>>> for a long time: I think trace statements should disappear in the
>>> release
>>>>>> JS build. Should we put all the JS trace code inside an if(goog.DEBUG)
>>>>>> block?
>>>>>>
>>>>>> Thanks,
>>>>>> Harbs
>>>>>
>>>>
>>>
>>>
>>
