I don't think you get my point, but let's discuss further after the
release.
Thanks,
-Alex
On 5/23/17, 3:03 PM, "Justin Mclean" wrote:
>Hi,
>
>> Interesting topic. Is this something that folks think is important for
>> this release?
>
>Again IMO no need to hold up this release.
>
>> I would no
Hi,
> Interesting topic. Is this something that folks think is important for
> this release?
Again IMO no need to hold up this release.
> I would not want to have a "no trace statements" policy. IMO trace
> statements are a useful tool when used appropriately. As long as the tool
> chain can
+1 for that
Am 23.05.17, 18:36 schrieb "Alex Harui" :
It might be as simple as not setting @export on Language.utils.trace. The
optimizer might then figure it out without having to add DEBUG defines.
Maybe something to investigate and discuss further after we get this
release out
It might be as simple as not setting @export on Language.utils.trace. The
optimizer might then figure it out without having to add DEBUG defines.
Maybe something to investigate and discuss further after we get this
release out?
-Alex
On 5/23/17, 8:03 AM, "Christofer Dutz" wrote:
>As far as I u
As far as I understood it, right now debug is the only option as all working on
larger applications can’t use the release build.
I think trace statements should eventually be wrapped by a “DEBUG” define to
allow including them and have them excluded by default.
We are talking about efficiency of
Interesting topic. Is this something that folks think is important for
this release?
I would not want to have a "no trace statements" policy. IMO trace
statements are a useful tool when used appropriately. As long as the tool
chain can remove trace statements in production code, that should be
Hi Justin,
+1
Agree with you, we should get rid of them.
Thanks,
Piotr
-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/FlexJS-trace-statements-in-SDK-code-tp61764p61766.html
Sent from the Apache Flex
Hi,
I’ve noticed in a few places there are some unnecessary trace statements in the
SDK. Like for instance here [1].
I’m thinking we probably shouldn’t have trace statements in production code.
Sonar cube flags it as an issue. [2] Anyone think otherwise?
On the JS side these are only omitted w
