I have some legacy JavaScript that I am trying to clean up, which of
course involves heavy linting  [;)]

The code was all global, of course, which I have wrapped in:

(function(){...})();

But one of the functions needs to be exposed globally, since I don't
want to modify all the uses of it throughout the application:

Before, it looked like this:
      function FormatMask(inputControl, format, regex){...}

In order to make it global, I added /*global FormatMask */ for JSLint
and then changed the code like this:

      FormatMask = function(inputControl, format, regex){...}

JSLint complains: Problem at line 131 character 5: Read only.

How can I fix this?



[Non-text portions of this message have been removed]

/*global FormatMask: true */

The ": true" part tells JSLint that that global variable is read-write, not
read-only.

Aseem

On Wed, Apr 21, 2010 at 1:44 PM, g2223060 <g2223060@...> wrote:

>
>
> I have some legacy JavaScript that I am trying to clean up, which of
> course involves heavy linting [;)]
>
> The code was all global, of course, which I have wrapped in:
>
> (function(){...})();
>
> But one of the functions needs to be exposed globally, since I don't
> want to modify all the uses of it throughout the application:
>
> Before, it looked like this:
> function FormatMask(inputControl, format, regex){...}
>
> In order to make it global, I added /*global FormatMask */ for JSLint
> and then changed the code like this:
>
> FormatMask = function(inputControl, format, regex){...}
>
> JSLint complains: Problem at line 131 character 5: Read only.
>
> How can I fix this?
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]

One of my favorites:

{dangling: 'commas',
  'in': 'object literals',
}



--- In jslint_com@yahoogroups.com, "Andrew" <adjohns@...> wrote:

> Can anyone think of some examples that I can include, or better yet, a webpage
that already discusses this kind of thing?
>

Is that possible?

IMHO, curly braces all over the place, even where they are not needed,
make readability worse. But that's my opinion, and I don't want to
argue.

--- In jslint_com@yahoogroups.com, "Felix E. Klee" <felix.klee@...> wrote:
>
> Is that possible?
>
> IMHO, curly braces all over the place, even where they are not needed,
> make readability worse. But that's my opinion, and I don't want to
> argue.

JSLint can do a much better job for you if you use braces consistently, so you
should use braces consistently. It is good that you do not want to argue.

JSLint doesn't like vendor extensions in pseudo-selectors, even with
the `css` options toggled.

I'm thinking specifically of `button:-moz-focus-inner`, which I'm
finding necessary to standardize a 3px-padding in Gecko's rendering of
buttons that's otherwise impossible to get rid of ( see
http://stopdesign.com/archive/2009/02/04/recreating-the-button.html#comment-4379
).  If you've got time to take a look, I'd like to see the following
snippet parse correctly:

     @charset "UTF-8";
     button::-moz-focus-inner {
         padding: 0;
         border-style: none;
     }

I've hacked together a workaround in my local copy, but I think it's
something that ought be addressed upstream.

Thanks for taking a look!

-Mike

I disagree.  Vendor specific CSS extensions are generally bad practice with
regards to conformance and efficient of CSS payload size.  The Mozilla specific
extensions are no better or worse than the IE specific hacks, which I absolutely
detest.  If JSLint wonders down this road it may never find its way back.

Austin

----- Original Message -----
From: Mike West <mike@...>
Date: Monday, April 26, 2010 17:32
Subject: [jslint] Vendor extensions in pseudoclasses
To: jslint_com@yahoogroups.com


> JSLint doesn't like vendor extensions in pseudo-selectors, even with
> the `css` options toggled.
>
> I'm thinking specifically of `button:-moz-focus-inner`, which I'm
> finding necessary to standardize a 3px-padding in Gecko's
> rendering of
> buttons that's otherwise impossible to get rid of ( see
> http://stopdesign.com/archive/2009/02/04/recreating-the-
> button.html#comment-4379
> ).  If you've got time to take a look, I'd like to see the following
> snippet parse correctly:
>
>    @charset "UTF-8";
>    button::-moz-focus-inner {
>        padding: 0;
>        border-style: none;
>    }
>
> I've hacked together a workaround in my local copy, but I think it's
> something that ought be addressed upstream.
>
> Thanks for taking a look!
>
> -Mike

Hi Douglas, I've got an idea here.
I don't know if you've already considered it, but you seem to have implemented
this idea to some degree with locating declared but unused variables in the
code.
But what would make lint so much more effective would be to locate objects that
have been declared and used, but in no way contribute to the return(s) of the
function(s).

Such an example, where the lint issues no warning:

function test() {
     var i, k;
     k = i + 1;
     i += 1;
     return i;
}

Do you have any plans for including a mapping of precedences and dependencies at
the variable level, or can you recommend a tool that does this?

On Mon, Apr 26, 2010 at 10:08 PM, Cheney, Edward A SSG RES USAR USARC
<austin.cheney@...> wrote:

> The Mozilla specific extensions are no better or worse than the
> IE specific hacks, which I absolutely detest.

1.  How do you feel about `img { -ms-interpolation-mode: bicubic; }`?
How about `-moz-border-radius`, etc?

2.  I'd argue that it's better to use standards-based expansion
mechanisms (vendor extensions are codified in the spec, and their
cross-browser behavior is clearly specified (that is, they're ignored
entirely, possibly invalidating the entire selector).  That's much
less risky than something like the star hack, or the miserable comment
hacks in earlier browsers.  In short, they're not _hacks_.

3.  Practically, there's no way of modifying 3 pixels of padding in
buttons rendered by Gecko.  Gecko provides a pseudo element that
allows manipulation of those three pixels.

-Mike

There are several different rendering engines available on the web.  They each
process presentation differently even when in full conformance to the
specification.  There is no reason to suggest then that a page must appear
identically in every detail in every browser.  All that really matter is that
branding is accurately preserved on all browser, the content remains accessible
to persons with mobility disabilities, and the content remains legible to visual
users.  Everything else is a luxury that demands your extra effort or
nonconforming code that will not pass through any validator.

Austin

----- Original Message -----
From: Mike West <mike@...>
Date: Tuesday, April 27, 2010 2:23
Subject: Re: [jslint] Vendor extensions in pseudoclasses
To: jslint_com@yahoogroups.com


> On Mon, Apr 26, 2010 at 10:08 PM, Cheney, Edward A SSG RES USAR USARC
> < wrote:
>
> > The Mozilla specific extensions are no better or worse than the
> > IE specific hacks, which I absolutely detest.
>
> 1.  How do you feel about `img { -ms-interpolation-mode: bicubic; }`?
> How about `-moz-border-radius`, etc?
>
> 2.  I'd argue that it's better to use standards-based expansion
> mechanisms (vendor extensions are codified in the spec, and their
> cross-browser behavior is clearly specified (that is, they're ignored
> entirely, possibly invalidating the entire selector).  That's much
> less risky than something like the star hack, or the miserable comment
> hacks in earlier browsers.  In short, they're not _hacks_.
>
> 3.  Practically, there's no way of modifying 3 pixels of padding in
> buttons rendered by Gecko.  Gecko provides a pseudo element that
> allows manipulation of those three pixels.
>
> -Mike

On Tue, Apr 27, 2010 at 10:55 AM, Cheney, Edward A SSG RES USAR USARC
<austin.cheney@...> wrote:

> There is no reason to suggest then that a page must appear identically
> in every detail in every browser.

Quite true.  This, however, is an argument against expending too much
effort in pursuit of pixel-perfection.  It's not an argument against
mechanisms that make that goal possible at all.

I think I can safely agree with pretty much everything you've written
in this email while at the same time maintaining that vendor-specific
enhancements and fixes are completely in keeping with the spirit of
the standard.  :)

-Mike

I see value in a lint tool for CSS that could be triggered to accept / reject
vendor-specific rendering rules, and a second trigger to accept / reject the
myriad of star and slash necessary to trigger specific browsers from a single
stylesheet.  It'd be nice also to validate to a specific CSS spec: 2.1, 3.0,
etc.  I don't believe JSLint is that tool.  I'd be comfortable if JSLint could
be driven to ignore anything between .  Of course if JSLint became a lint tool
for CSS checking, I'd love it.  I'd also love if it had options for HTML
validation -- match the doctype found, match a specified doctype, insure script
tags don't self-close, optionally validate HTML 5 inclusion/exclusion, insure
nested object tags necessary for most browsers, etc, etc.  Alas, I think the
going consensus is (with small exception) JSLint is best as a JavaScript lint
tool, and not intended to be an all-in-wonder web verifier. 
http://validator.w3.org/ does the HTML,
  http://jigsaw.w3.org/css-validator/ does the CSS, though both are best as
online tools and don't really support off-line without linux.  Since the 3 types
of content should be in separate files, in theory they can be validated
separately.

Mike, to that end, put this offending CSS in an external stylesheet.  Then
JSLint will only validate you have a well-formed link tag, and leave your CSS
preferences alone.  Granted, we could fuel the discussion of the stylistic
merits ad nauseum, but I think you've made it clear that's not the answer you're
looking for.

Mike,




________________________________
From: Mike West <mike@...>
To: jslint_com@yahoogroups.com
Sent: Mon, April 26, 2010 6:01:48 AM
Subject: [jslint] Vendor extensions in pseudoclasses


JSLint doesn't like vendor extensions in pseudo-selectors, even with
the `css` options toggled.

I'm thinking specifically of `button:-moz- focus-inner` , which I'm
finding necessary to standardize a 3px-padding in Gecko's rendering of
buttons that's otherwise impossible to get rid of ( see
http://stopdesign. com/archive/ 2009/02/04/ recreating- the-button.
html#comment- 4379
).  If you've got time to take a look, I'd like to see the following
snippet parse correctly:

@charset "UTF-8";
button::-moz- focus-inner {
padding: 0;
border-style: none;
}

I've hacked together a workaround in my local copy, but I think it's
something that ought be addressed upstream.

Thanks for taking a look!

-Mike





[Non-text portions of this message have been removed]

On Tue, Apr 27, 2010 at 5:40 PM, Rob Richardson <erobrich@...> wrote:

> Alas, I think the going consensus is (with small exception) JSLint is best as
> a JavaScript lint tool, and not intended to be an all-in-wonder web verifier.

I understand that, and also see value in concentrating effort on the
areas in which JSLint most clearly shows value.  I wasn't expecting to
get into an argument about the appropriateness of CSS I'm writing,
this obviously isn't the correct forum for that discussion.  This will
be my last message on the topic.

My point is simple.  JSLint does, at the moment, parse CSS.  It
attempts to validate CSS in a very practical way (that is, it accepts
CSS with the conventional hacks that are necessary to do work on
today's web) in a way that the CSS Validator doesn't.  That's valuable
to me, and I think it's generally valuable.

The inconsistency I've run into, which is solved via the vendor
extension, falls into the same category of practical resolutions to
problems with cross-browser web development.  Further, it's consistent
with JSLint's current acceptance of vendor extensions for properties
(the IE resize mode I noted yesterday, for example, passes linting).
I'd recommend that support be added into JSLint for these types of
pseudoclasses as well.

In the hopes of helping someone else work around the issue, I'll note
the 7-line change that I'm using locally below.  I don't think it's
the _right_ way to add the functionality, but it works for me.

Thanks!

-Mike

--- Diff follows, though line numbers won't line up with the current
version... ---

diff --git a/scripts/lib/jslint.js b/scripts/lib/jslint.js
index 05a2283..f270620 100644
--- a/scripts/lib/jslint.js
+++ b/scripts/lib/jslint.js
@@ -884,7 +884,7 @@ var JSLINT = (function () {
  // url badness
          ux = /&|\+|\u00AD|\.\.|\/\*|%[^;]|base64|url|expression|data|mailto/i,
  // style
-        sx =
/^\s*([{:#%.=,>+\[\]@()"';]|\*=?|\$=|\|=|\^=|~=|[a-zA-Z_][a-zA-Z0-9_\-]*|[0-9]+|\
<\/|\/\*)/,
+        sx =
/^\s*([{:#%.=,>+\[\]@()"';]|\*=?|\$=|\|=|\^=|~=|[a-zA-Z_\-][a-zA-Z0-9_\-]*|[0-9]\
+|<\/|\/\*)/,
          ssx =
/^\s*([@#!"'};:\-%.=,+\[\]()*_]|[a-zA-Z][a-zA-Z0-9._\-]*|\/\*?|\d+(?:\.\d+)?|<\/\
)/,
  // attributes characters
          qx = /[^a-zA-Z0-9-_\/ ]/,
@@ -3367,8 +3367,12 @@ loop:   for (;;) {
                      advance(')');
                      break;
                  default:
-                    warning("Expected a pseudo, and instead saw :{a}.",
-                        nexttoken, nexttoken.value);
+                    if ( option.css && nexttoken.value[ 0 ] === '-' ) {
+                        advance();
+                    } else {
+                        warning("Expected a pseudo, and instead saw :{a}.",
+                            nexttoken, nexttoken.value);
+                    }
                  }
                  break;
              case '#':

"between ." came from "between style tags" except I conveyed it as markup. The
markup apparently got trimmed by my email program.  What a wonderful world where
we converse in HTML about HTML and our tools get confused on which we meant.  :D

Rob





________________________________
From: Rob Richardson <erobrich@...>
To: jslint_com@yahoogroups.com
Sent: Tue, April 27, 2010 8:40:56 AM
Subject: Re: [jslint] Vendor extensions in pseudoclasses


I see value in a lint tool for CSS that could be triggered to accept / reject
vendor-specific rendering rules, and a second trigger to accept / reject the
myriad of star and slash necessary to trigger specific browsers from a single
stylesheet.  It'd be nice also to validate to a specific CSS spec: 2.1, 3.0,
etc.  I don't believe JSLint is that tool.  I'd be comfortable if JSLint could
be driven to ignore anything between .  Of course if JSLint became a lint tool
for CSS checking, I'd love it.  I'd also love if it had options for HTML
validation -- match the doctype found, match a specified doctype, insure script
tags don't self-close, optionally validate HTML 5 inclusion/exclusion , insure
nested object tags necessary for most browsers, etc, etc.  Alas, I think the
going consensus is (with small exception) JSLint is best as a JavaScript lint
tool, and not intended to be an all-in-wonder web verifier. http://validator.
w3.org/ does the HTML,
http://jigsaw. w3.org/css- validator/ does the CSS, though both are best as
online tools and don't really support off-line without linux.  Since the 3 types
of content should be in separate files, in theory they can be validated
separately.

Mike, to that end, put this offending CSS in an external stylesheet.  Then
JSLint will only validate you have a well-formed link tag, and leave your CSS
preferences alone.  Granted, we could fuel the discussion of the stylistic
merits ad nauseum, but I think you've made it clear that's not the answer you're
looking for.

Rob





[Non-text portions of this message have been removed]

On Tue, Apr 27, 2010 at 12:43 PM, Rob Richardson <erobrich@...> wrote:
> http://validator. w3.org/ does the HTML,
> http://jigsaw. w3.org/css- validator/ does the CSS,
> though both are best as online tools and don't really support off-line without
linux.

I'm surprised to hear you say that these only run on linux, as I am
able to do command-line validation of CSS and HTML on Windows and Mac
as well.

Great instructions on setting up the w3 CSS validator for use on the
command line, are to be found in the EmacsWiki:
http://www.emacswiki.org/emacs/FlymakeCSS

And Tidy is an excellent command-line tool for HTML validation. It's
included with Cygwin, Macports or Fink.  Tidy is technically a linter,
not a validator, but in practice it catches all the issues that the w3
validation service does.
http://www.w3.org/People/Raggett/tidy/

And if you really want true SGML validation, just like the w3
validation service, there is onsgmls.  It's also included with Cygwin,
Macports and Fink; but you'd also need to grab the w3's DTD library (
http://validator.w3.org/sgml-lib.tar.gz ) and then learn how to invoke
the tool properly.  IMO Tidy is much easier to use and onsgmls doesn't
provide any extra value, but if you really want to use onsgmls, these
links should get you started in the right direction:
http://onemorebug.com/blog/2007/10/28/html-validation/
http://snipplr.com/view/4970/validate-xhtml-with-tidy-andor-openjade-just-like-t\
he-ff-extension/

I hope this information is helpful to others, and that I've not
strayed too far off-topic.

--
Noah Sussman
Software Historian
@noahsussman

A foolish consistency is the hobgoblin of little minds
       -- Emerson

JSLint reports that anonymous functions such as this:

var f = function(args) {
    // body
}

would be better like this:

var f = function (args) {
    // body
}

Why is the space between 'function' and '(' preferable?

Rob





[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, Rob Richardson <erobrich@...> wrote:
>
> JSLint reports that anonymous functions such as this:
>
> var f = function(args) {
>    // body
> }
>
> would be better like this:
>
> var f = function (args) {
>    // body
> }
>
> Why is the space between 'function' and '(' preferable?

It is for readability. It makes it clearer that you are creating a function and
not calling a function.

Also, you forgot the semicolon.

That is not an anonymous function.

The follow two are identical.

var f = function () {
     // body
};

function f () {
     // body
}

In both cases you are assigning a function to a named variable in a given
namespace.  The biggest difference is the semicolon at the end of the first
example, but for your consideration the difference is whether the namespace
assignment is implicit to a command or explicitly stated.  An anonymous function
is a function not assigned to a name.  This is an example of an anonymous
function:

errorp.sort(function (a, b) {
     return a - b;
});

Austin

----- Original Message -----
From: Douglas Crockford <douglas@...>
Date: Saturday, May 1, 2010 23:53
Subject: [jslint] Re: function() -> function ()
To: jslint_com@yahoogroups.com


> --- In jslint_com@yahoogroups.com, Rob Richardson < wrote:
> >
> > JSLint reports that anonymous functions such as this:
> >
> > var f = function(args) {
> >    // body
> > }
> >
> > would be better like this:
> >
> > var f = function (args) {
> >    // body
> > }
> >
> > Why is the space between 'function' and '(' preferable?
>
> It is for readability. It makes it clearer that you are creating a function
and not calling a function.
>
> Also, you forgot the semicolon.
>

Identical?  Have you ever heard the expression "not always right, but never in
doubt"?

What should the following show?

var f = function () {
};

function g() {
}
alert(f.name == g.name);


By any ordinary sense "identical", you'd think it would pop-up "true", but lo,
f.name is undefined but g.name is "g".

The function pointed to by f is anonymous in the sense that it does not know its
own name, although other functions may have a name for it (indeed, it any
function does not appear somewhere in the namespace, it's unreferenced and so,
can never be called and will be cleaned up by the GC.

M.







________________________________
From: "Cheney, Edward A SSG RES USAR USARC" <austin.cheney@...>
To: jslint_com@yahoogroups.com
Sent: Sun, May 2, 2010 2:56:23 PM
Subject: Re: [jslint] Re: function() -> function ()

That is not an anonymous function.

The follow two are identical.

var f = function () {
     // body
};

function f () {
     // body
}

In both cases you are assigning a function to a named variable in a given
namespace.  The biggest difference is the semicolon at the end of the first
example, but for your consideration the difference is whether the namespace
assignment is implicit to a command or explicitly stated.  An anonymous function
is a function not assigned to a name.  This is an example of an anonymous
function:

errorp.sort(function (a, b) {
     return a - b;
});

Austin

----- Original Message -----
From: Douglas Crockford <douglas@...>
Date: Saturday, May 1, 2010 23:53
Subject: [jslint] Re: function() -> function ()
To: jslint_com@yahoogroups.com


> --- In jslint_com@yahoogroups.com, Rob Richardson < wrote:
> >
> > JSLint reports that anonymous functions such as this:
> >
> > var f = function(args) {
> >    // body
> > }
> >
> > would be better like this:
> >
> > var f = function (args) {
> >    // body
> > }
> >
> > Why is the space between 'function' and '(' preferable?
>
> It is for readability. It makes it clearer that you are creating a function
and not calling a function.
>
> Also, you forgot the semicolon.
>


------------------------------------

Yahoo! Groups Links



[Non-text portions of this message have been removed]

On Sun, May 2, 2010 at 2:56 PM, Cheney, Edward A SSG RES USAR USARC <
austin.cheney@...> wrote:

>
>
> That is not an anonymous function.
>
> The follow two are identical.
>
> var f = function () {
> // body
> };
>
> function f () {
> // body
> }
>
> They are not identical. This is a function declaration vs function
expression. Consider the following:

f();
function f () {}

This works because function declarations are hoisted to the top of the
containing scope, changing this example to function expression:

f();
var f = function () {};

This will cause an error (line 1), because the function isn't available in
the variable f (line 2) which is not executed.

By readability, I think Doug means:

either
var f = function (args) {};
or
function f (args) {}

are clearly creating a function f

where

f('foobar');

is clearly calling f.

*note the space when creating f and no space when calling f

Marcel


[Non-text portions of this message have been removed]

I've typically used the keyword 'function' to denote that I'm creating a
function.  In quick testing, I find no way to call a function with the keyword
'function' present ... short of creating a Function.doit = function () {...
which just seems silly, and no way to create a function called 'function'
without similar pain.  Is there a way to invoke a function with the 'function'
keyword present?  What's an (albeit likely horrid) example where one could get
confused between creation and invocation due to similar syntax?

Rob





________________________________
From: Douglas Crockford <douglas@...>
To: jslint_com@yahoogroups.com
Sent: Sat, May 1, 2010 12:18:24 PM
Subject: [jslint] Re: function() -> function ()


--- In jslint_com@yahoogro ups.com, Rob Richardson <erobrich@.. .> wrote:
>
> JSLint reports that anonymous functions such as this:
>
> var f = function(args) {
>    // body
> }
>
> would be better like this:
>
> var f = function (args) {
>    // body
> }
>
> Why is the space between 'function' and '(' preferable?

It is for readability. It makes it clearer that you are creating a function and
not calling a function.

Also, you forgot the semicolon.





[Non-text portions of this message have been removed]

On Mon, May 3, 2010 at 12:06 PM, Rob Richardson <erobrich@...> wrote:

>Is there a way to invoke a function with the 'function' keyword present?

(function (foo) {
                        return foo;
                       })('bar');


--
Noah Sussman
Software Historian
@noahsussman

A foolish consistency is the hobgoblin of little minds
       -- Emerson

You're creating it with 'function' then invoking it right away.  Is there a
similar way to use the keyword 'function' to call a previously defined function?
If not, it seems sufficient to note the keyword 'function' will define a
function, and it's absence will invoke it.  The presence or absence of a space
is helpful, but the convention is recent and seems somewhat contrived.  Reading
code of those who don't subscribe to it will lead to misunderstanding.  It seems
the presence of the word 'function' is a much better identifier of the purpose
of the statement than the presence of a space before the parens.

Rob





________________________________
From: Noah Sussman <noah@...>
To: jslint_com@yahoogroups.com
Sent: Mon, May 3, 2010 9:42:38 AM
Subject: Re: [jslint] Re: function() -> function ()


On Mon, May 3, 2010 at 12:06 PM, Rob Richardson <erobrich@yahoo. com> wrote:

>Is there a way to invoke a function with the 'function' keyword present?

(function (foo) {
return foo;
})('bar');

--
Noah Sussman
Software Historian
@noahsussman

A foolish consistency is the hobgoblin of little minds
        -- Emerson





[Non-text portions of this message have been removed]

Michael,

Your example is partially accurate, but consider the following:

var f = function () {};
function g () {}

if (typeof(f) === typeof(g)) {
alert(typeof(f) + "\n" + f + "\n" + g);
}

You are correct in that a name property is supplied to the second of these two
cases.  But the types are identical and variable f has an anonymous function
assigned to it.  Since f is a named variable with a function as its value it is
a function that is not anonymous.  JavaScript is a lambda language of downward
inheritance that allows accidental creation of global variables.  With regard to
complex instances of inheritance where closures are used across the variance
namespace scopes you have to be sure where your variables are defined to prevent
collisions, especially with consideration for reuse.  The first convention
forces strict awareness of variable declaration, because the function must be
declared before it can be executed.  The second convention supplies no such
awareness, which is potentially problematic with regards to instantiation and
invocation as closure in complex logic prior described.  Fortunately, JSLint is
smart enough to throw an error when a function is used before it is declared. 
Since the two conventions are identical in representation I would suggest only
using the one that is not open to abuse from flawed and sloppy programming.

Austin

----- Original Message -----
From: Michael Lorton <mlorton@...>
Date: Monday, May 3, 2010 2:38
Subject: Re: [jslint] Re: function() -> function ()
To: jslint_com@yahoogroups.com


> Identical?  Have you ever heard the expression "not always right,
> but never in doubt"?
>
> What should the following show?
>
> var f = function () {
> };
>
> function g() {
> }
> alert(f.name == g.name);
>
>
> By any ordinary sense "identical", you'd think it would pop-up
> "true", but lo, f.name is undefined but g.name is "g".
>
> The function pointed to by f is anonymous in the sense that it does
> not know its own name, although other functions may have a name for
> it (indeed, it any function does not appear somewhere in the
> namespace, it's unreferenced and so, can never be called and will
> be cleaned up by the GC.
>
> M.

$0.02:

First, "the good parts" advocates the following form, as it illustrates the true
nature of functions:

1. var fnOnClick = function (){ ... };

Others advocate you should always name your functions for the benefit of stack
traces.  I think this is what Mr. Lorton's test code illustrates:

2. function fnOnClick (){ ... }

One can combine the two, but its almost certainly bad practice because keeping
two names in sync is invites mismatch errors:

3. var fnOnClick = function fnOnClick (){ ... };

Method (1) works fine with stack traces in the most current versions of Firebug,
so appears to be the best solution for my purposes.  IIRC, that was not the case
until recently.

Cheers, Mike






________________________________
From: Michael Lorton <mlorton@...>
To: jslint_com@yahoogroups.com
Sent: Sun, May 2, 2010 3:07:45 PM
Subject: Re: [jslint] Re: function() -> function ()


Identical?  Have you ever heard the expression "not always right, but never in
doubt"?

What should the following show?

var f = function () {
};

function g() {
}
alert(f.name == g.name);

By any ordinary sense "identical", you'd think it would pop-up "true", but lo,
f.name is undefined but g.name is "g".

The function pointed to by f is anonymous in the sense that it does not know its
own name, although other functions may have a name for it (indeed, it any
function does not appear somewhere in the namespace, it's unreferenced and so,
can never be called and will be cleaned up by the GC.

M.

____________ _________ _________ __
From: "Cheney, Edward A SSG RES USAR USARC" <austin.cheney@ us.army.mil>
To: jslint_com@yahoogro ups.com
Sent: Sun, May 2, 2010 2:56:23 PM
Subject: Re: [jslint] Re: function() -> function ()

That is not an anonymous function.

The follow two are identical.

var f = function () {
// body
};

function f () {
// body
}

In both cases you are assigning a function to a named variable in a given
namespace.  The biggest difference is the semicolon at the end of the first
example, but for your consideration the difference is whether the namespace
assignment is implicit to a command or explicitly stated.  An anonymous function
is a function not assigned to a name.  This is an example of an anonymous
function:

errorp.sort( function (a, b) {
return a - b;
});

Austin

----- Original Message -----
From: Douglas Crockford <douglas@crockford. com>
Date: Saturday, May 1, 2010 23:53
Subject: [jslint] Re: function() -> function ()
To: jslint_com@yahoogro ups.com

> --- In jslint_com@yahoogro ups.com, Rob Richardson < wrote:
> >
> > JSLint reports that anonymous functions such as this:
> >
> > var f = function(args) {
> >    // body
> > }
> >
> > would be better like this:
> >
> > var f = function (args) {
> >    // body
> > }
> >
> > Why is the space between 'function' and '(' preferable?
>
> It is for readability. It makes it clearer that you are creating a function
and not calling a function.
>
> Also, you forgot the semicolon.
>

------------ --------- --------- ------

Yahoo! Groups Links

[Non-text portions of this message have been removed]




[Non-text portions of this message have been removed]

As a developer, I use the console.log() function (or ADSAFE.log() internal to an
adsafe widget) frequently to debug my code.

I've noticed that when there is an error within an ADSAFE widget, the console
reads "uncaught exception: [object Object]" and cannot be inspected further.

Since try/catch blocks seem to be discouraged within an ADSafe widget, what do
you suggest the best way to report the details of those errors are to
developers? I've found that it is sufficient for my work to simply add
ADSAFE.log(e) to the three catch blocks within the adsafe.js code (which
displays the full contents of the error object so that it can be inspected).  Is
this something that could (should?) go into the master version of adsafe.js?

Thanks for all of the great work on ADSafe so far -- I'm excited to build some
cool things with it.

Cheers,
Adam

Since ADSafe widgets are basically sandboxed javascript/dom apps, is there any
suggestion on how to nicely shut them down (such as an ADSAFE.stop() function)?

For example, widgets can be added/removed at any time by the host page, but it
might be nice to save some state before closing/removing a widget in case the
user has modified it or interacted with it somehow.

Any thoughts on how to play nicely with interactive, data-rich widgets?

Cheers,
Adam

--- In jslint_com@yahoogroups.com, "adam.kumpf" <adam.kumpf@...> wrote:
> Since ADSafe widgets are basically sandboxed javascript/dom apps, is there any
suggestion on how to nicely shut them down (such as an ADSAFE.stop() function)?
>
> For example, widgets can be added/removed at any time by the host page, but it
might be nice to save some state before closing/removing a widget in case the
user has modified it or interacted with it somehow.
>
> Any thoughts on how to play nicely with interactive, data-rich widgets?


You can call the widget's .remove() method.

--- In jslint_com@yahoogroups.com, "adam.kumpf" <adam.kumpf@...> wrote:
> As a developer, I use the console.log() function (or ADSAFE.log() internal to
an adsafe widget) frequently to debug my code.
>
> I've noticed that when there is an error within an ADSAFE widget, the console
reads "uncaught exception: [object Object]" and cannot be inspected further.
>
> Since try/catch blocks seem to be discouraged within an ADSafe widget, what do
you suggest the best way to report the details of those errors are to
developers? I've found that it is sufficient for my work to simply add
ADSAFE.log(e) to the three catch blocks within the adsafe.js code (which
displays the full contents of the error object so that it can be inspected).  Is
this something that could (should?) go into the master version of adsafe.js?


Please let me see your suggestions.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "adam.kumpf" <adam.kumpf@> wrote:
> > As a developer, I use the console.log() function (or ADSAFE.log() internal
to an adsafe widget) frequently to debug my code.
> >
> > I've noticed that when there is an error within an ADSAFE widget, the
console reads "uncaught exception: [object Object]" and cannot be inspected
further.
> >
> > Since try/catch blocks seem to be discouraged within an ADSafe widget, what
do you suggest the best way to report the details of those errors are to
developers? I've found that it is sufficient for my work to simply add
ADSAFE.log(e) to the three catch blocks within the adsafe.js code (which
displays the full contents of the error object so that it can be inspected).  Is
this something that could (should?) go into the master version of adsafe.js?
>
>
> Please let me see your suggestions.
>


Hi Doug,

I added the ADSAFE.log() call to all three try/catch blocks.  The most notable
of which was when calling the supplied function:


try {
     f(dom, adsafe_lib);
} catch (e) {
     ADSAFE.log(e); // print error object for further inspection.
     return error();
}


There are two other places as well where the catch was ignored.  I added the
same line there as well:


} catch (ignore) {
     ADSAFE.log(ignore);
}


Another way (which may make more sense) would be to add the ADSAFE.log() call in
the error() function before throwing the exception.  This is probably the way to
go since it doesn't string the error output over three different places:


function error(message) {
     ADSAFE.log("ADsafe error: " + (message || "ADsafe violation."));
     throw {
         name: "ADsafe",
         message: message || "ADsafe violation."
     };
}


Best,
Adam