javascript.options.strict and performance

[John J Barton]

I don't recommend running Firebug with javascript.options.strict set
true:
http://blog.getfirebug.com/2009/09/08/javascript-options-strict-and-performance/

jjb

[Davide Ficano]

On 9 Set, 07:56, John J Barton <johnjbar...@johnjbarton.com> wrote:
> I don't recommend running Firebug with  javascript.options.strict set

> true:http://blog.getfirebug.com/2009/09/08/javascript-options-strict-and-p...
>
> jjb

javascript.options.strict should can impact dramatically on
performances, if it is enabled on main firefox profile navigation can
be painful and error console can contain thousands of warnings.

I don't like JSLint, it doesn't work perfectly with "namespaces" and
produces false problems with getters

Try the class shown below

function DemoClass() {

}

DemoClass.prototype = {
get name() {
return "bob";
}
}

I prefer the Rhino command line tool js that is easy to run from
editors, Komodo uses it by default

[brothercake]

But wouldn't a far more appropriate conclusion to this, from Firebug's
point of view, be to fix Firebug so that it doens't generate strict
warnings? In the example you've cited, Firefox is correct to issue a
warning - you shouldn't let a function return undefined - undefined is
not a value.

[johnjbarton]

On Sep 9, 11:16 pm, brothercake <brotherc...@gmail.com> wrote:
> But wouldn't a far more appropriate conclusion to this, from Firebug's
> point of view, be to fix Firebug so that it doens't generate strict

This hammer is too large by a factor of 10 and the head is on
backwards. So should we fix the hammer or use it even though it will
damage the woodwork and miss half the nails?

I say 'no'. We should insist that mozilla fix the hammer then apply
it.

> warnings? In the example you've cited, Firefox is correct to issue a
> warning - you shouldn't let a function return undefined - undefined is
> not a value.

In this conclusion we disagree. "undefined" is a valid value and
valuable return value from a function, serving for Javascript what the
pointer value zero does for C code.

jjb

[brothercake]

> This hammer is too large by a factor of 10 and the head is on
> backwards. So should we fix the hammer or use it even though it will
> damage the woodwork and miss half the nails?

We use higher quality wood!

> In this conclusion we disagree. "undefined" is a valid value and
> valuable return value from a function, serving for Javascript what the
> pointer value zero does for C code.

null serves that purpose in JavaScript. null is a value. undefined is
a primitive data type.

[johnjbarton]

On Sep 10, 9:25 am, brothercake <brotherc...@gmail.com> wrote:
...>

> > In this conclusion we disagree. "undefined" is a valid value and
> > valuable return value from a function, serving for Javascript what the
> > pointer value zero does for C code.
>
> null serves that purpose in JavaScript. null is a value. undefined is
> a primitive data type.

Exactly. So the proper return type from a function that "gets" a value
from a table when the key maps to no cell in the table is "undefined",
not 'null'. The value in the table is not 'null'. The entry is
undefined.

jjb

[brothercake]

Myeah. fair enough :)

So I agree that the console should provide a way of filtering out
chrome errors and warnings from document errors and warnings, but
apart from that, is there the suggestion that it's reporting warnings
that it shouldn't be reporting at all?

(sorry if it this wandering OT for firebug discussion, it's just
peaked my interest!)

[johnjbarton]

On Sep 10, 1:52 pm, brothercake <brotherc...@gmail.com> wrote:
> Myeah. fair enough :)
>
> So I agree that the console should provide a way of filtering out
> chrome errors and warnings from document errors and warnings, but
> apart from that, is there the suggestion that it's reporting warnings
> that it shouldn't be reporting at all?

Some would take my ranting on the subject as somewhat beyond
"suggestion" ;-).

I think 'strict' is just broken because the rules it implements are
not helpful and it does not implement rules that would be helpful. As
far as I know 'strict' is not based on analysis of the problems the
developers actually have, but rather it is based on the idea the
Javascript really should have been a different language than it is.

I have a similar complaint about JSLint, but at least it is well
supported, documented, and has lots of optional controls.

jjb