Hello!
I think really neat would be something that generates the
jslint-options-string (/*jslint ... */).
I am writing a small Javascript Library and had the good-parts
and the assume-a-browser in my jslint-options; now I learned
the good-parts have altered and I manually changed the string.
I wrote myself this method to run in the js-console to get the
checked options more convenient.

var getJSLintOptions = function () {
     var result = [],
         walkTheDom = function walk(node, func) {
             func(node);
             node = node.firstChild;

             while (node) {
                 walk(node, func);
                 node = node.nextSibling;
             }
         };

     walkTheDom(document.getElementById("options"), function (node) {
         var nodeName = node.nodeName.toLowerCase(),
             id, type;
         if (nodeName === "input") {
             id = node.getAttribute("id");
             type = node.getAttribute("type");
             if (type === "checkbox" && node.checked) {
                 result.push(id + ": true");
             }
             if (type === "text" && node.value) {
                 result.push(id + ": " + node.value);
             }
         }
     });

     result = "\/*jslint " + result.join(", ") + " *\/";
     return result;
};

For this is my first post here, I think I might conclude:
Thanks for JSLint (and the walkTheDom method)

Christian

--- In jslint_com@yahoogroups.com, "crlender" <crlender@...> wrote:
>
> In your example, if foo is not declared, it will result in a
> ReferenceError being thrown. This won't happen if you test with the
> typeof operator. I think DC's point was about avoiding the reference
> to 'window' when testing for a global variable, since 'window' is no
> longer part of option.browser.
>
> In addition to that, '!foo' converts a value to boolean, and some
> host objects (especially in IE) are known to throw exceptions if
> you try that. typeof is always safe*.
>
>   - Conrad
>
>
> * Except, I think, in one weird Safari 2 bug when items of a
> NodeList are checked, but I'd have to look that up.
>

I see; thank you. Another question, why use:
if (typeof console === 'object') {

Instead of:
if (console instanceof Object) {

?

As far as I know, if "console" is null, typeof will return 'object', which would
break the first code.

P.S. I know what the point of Douglas' post is, but he brought up the idea of
using typeof, and I was curious why he recommended it, rather than an
alternative.

I disagree. Not with the ”single object” approach, that is a very good practice,
but that libraries usually refer to themselves. I have a multitude of “classes”
in the various projects I work on – they are all a single js file which declares
a single global variable, and not a single one of them refers to itself by name.
Why should it?

In the case of general utility libraries such as Prototype or jQuery then yes,
they probably all refer to themselves, but they are the exception, not the norm.

/Jakob

From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On Behalf
Of Michael Lorton
Sent: 2. maj 2009 07:01
To: jslint_com@yahoogroups.com
Subject: Re: [jslint] JSLint doesn't check if global variables are used.





You're right, of course, but even a library should avoid polluting the global
names space any more than necessary. I prefer to have all the library's
functions wrapped up in a single object, e.g.:

var MyLib = {
myFirstFunction : function () { ...},
mySecondFunction : function () { ...}, ,,,

};

Usually, the library will refer to itself at least once, obviating need there
for an /*external */ tag.

M.

________________________________
From: Jakob Kruse <kruse@...>
To: jslint_com@yahoogroups.com
Sent: Friday, May 1, 2009 1:24:47 PM
Subject: RE: [jslint] JSLint doesn't check if global variables are used.

Actually, that is very common. The purpose of most libraries is to declare
global variables for use elsewhere.

/Jakob

From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On Behalf
Of Michael Lorton
Sent: 1. maj 2009 18:47
To: jslint_com@yahoogroups.com
Subject: Re: [jslint] JSLint doesn't check if global variables are used.

The /*global */ tag solves the reverse problem: how tell if a variable used here
is declared elsewhere.

Perhaps we need a /*external */ tag that asserts a variable declared here is
used elsewhere. Personally, I would oppose it (mildly): if you aren't using it
here, why are you declaring it here, hmmm?

M.

________________________________
From: pauanyu <pcxunlimited@...>
To: jslint_com@yahoogroups.com
Sent: Friday, May 1, 2009 9:35:54 AM
Subject: Re: [jslint] JSLint doesn't check if global variables are used.

--- In jslint_com@yahoogroups.com, Michael Lorton <mlorton@...> wrote:
>
> In a formal sense, it's a bug, but how could it be fixed? A global variable
might be used by a different script, or by a bit of Javascript in an event
handler, even by Flash. There's no way to tell if one is never used.
>
> Another reason that Global Variables Suck.
>
> M.

As to your first point.. JSLint supports the /*global */ construct for global
variables defined elsewhere.

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

Yahoo! Groups Links

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

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

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

Yahoo! Groups Links

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


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

Really?  Your libraries never have externally available functions or data that
they themselves use?

You could always do this, I suppose:

var myModule = ( function() {
    var utilityFunction = function() { ... };
    return {
        utilityFunction : utilityFunction,
        someOtherFunction : function() {
               ...
               utilityFunction();
               ....
      }
    }
})();

That is, you could have an internal reference for each function (or datum) that
is only reachable through the closure and an external reference the library
itself never uses -- but why you would do so, other than to trigger a misleading
global myModule not used error, I don't know why you would.  Am I missing
something?

M.




________________________________
From: Jakob Kruse <kruse@...>
To: jslint_com@yahoogroups.com
Sent: Tuesday, May 5, 2009 9:11:46 AM
Subject: RE: [jslint] JSLint doesn't check if global variables are used.

I disagree. Not with the ”single object” approach, that is a very good
practice, but that libraries usually refer to themselves. I have a multitude of
“classes” in the various projects I work on – they are all a single js
file which declares a single global variable, and not a single one of them
refers to itself by name. Why should it?

In the case of general utility libraries such as Prototype or jQuery then yes,
they probably all refer to themselves, but they are the exception, not the norm.

/Jakob

From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On Behalf
Of Michael Lorton
Sent: 2. maj 2009 07:01
To: jslint_com@yahoogroups.com
Subject: Re: [jslint] JSLint doesn't check if global variables are used.





You're right, of course, but even a library should avoid polluting the global
names space any more than necessary. I prefer to have all the library's
functions wrapped up in a single object, e.g.:

var MyLib = {
myFirstFunction : function () { ...},
mySecondFunction : function () { ...}, ,,,

};

Usually, the library will refer to itself at least once, obviating need there
for an /*external */ tag.

M.

________________________________
From: Jakob Kruse <kruse@...>
To: jslint_com@yahoogroups.com
Sent: Friday, May 1, 2009 1:24:47 PM
Subject: RE: [jslint] JSLint doesn't check if global variables are used.

Actually, that is very common. The purpose of most libraries is to declare
global variables for use elsewhere.

/Jakob

From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On Behalf
Of Michael Lorton
Sent: 1. maj 2009 18:47
To: jslint_com@yahoogroups.com
Subject: Re: [jslint] JSLint doesn't check if global variables are used.

The /*global */ tag solves the reverse problem: how tell if a variable used here
is declared elsewhere.

Perhaps we need a /*external */ tag that asserts a variable declared here is
used elsewhere. Personally, I would oppose it (mildly): if you aren't using it
here, why are you declaring it here, hmmm?

M.

________________________________
From: pauanyu <pcxunlimited@...>
To: jslint_com@yahoogroups.com
Sent: Friday, May 1, 2009 9:35:54 AM
Subject: Re: [jslint] JSLint doesn't check if global variables are used.

--- In jslint_com@yahoogroups.com, Michael Lorton <mlorton@...> wrote:
>
> In a formal sense, it's a bug, but how could it be fixed? A global variable
might be used by a different script, or by a bit of Javascript in an event
handler, even by Flash. There's no way to tell if one is never used.
>
> Another reason that Global Variables Suck.
>
> M.

As to your first point.. JSLint supports the /*global */ construct for global
variables defined elsewhere.

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

Yahoo! Groups Links

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

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

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

Yahoo! Groups Links

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


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



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

Yahoo! Groups Links



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

Yes, really. I fail to see why I would want to reference the global from within
its own declaration?

That said, this discussion has gotten quite a bit off track. The only possible
purpose of declaring a global variable/function/object/whatever is so that it
can be accessed globally – from everywhere, and in particular, from elsewhere.
I find the current behavior of JSLint (not forcing me to declare globals twice
for clarity) to be correct. Declaring a global in some file and not using it in
that file (but possibly in every other file loaded) should not result in errors
or warnings.

/Jakob

From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On Behalf
Of Michael Lorton
Sent: 5. maj 2009 18:24
To: jslint_com@yahoogroups.com
Subject: Re: [jslint] JSLint doesn't check if global variables are used.





Really? Your libraries never have externally available functions or data that
they themselves use?

You could always do this, I suppose:

var myModule = ( function() {
var utilityFunction = function() { ... };
return {
utilityFunction : utilityFunction,
someOtherFunction : function() {
...
utilityFunction();
....
}
}
})();

That is, you could have an internal reference for each function (or datum) that
is only reachable through the closure and an external reference the library
itself never uses -- but why you would do so, other than to trigger a misleading
global myModule not used error, I don't know why you would. Am I missing
something?

M.

________________________________
From: Jakob Kruse <kruse@...>
To: jslint_com@yahoogroups.com
Sent: Tuesday, May 5, 2009 9:11:46 AM
Subject: RE: [jslint] JSLint doesn't check if global variables are used.

I disagree. Not with the ”single object” approach, that is a very good
practice, but that libraries usually refer to themselves. I have a multitude of
“classes” in the various projects I work on – they are all a single js
file which declares a single global variable, and not a single one of them
refers to itself by name. Why should it?

In the case of general utility libraries such as Prototype or jQuery then yes,
they probably all refer to themselves, but they are the exception, not the norm.

/Jakob

From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On Behalf
Of Michael Lorton
Sent: 2. maj 2009 07:01
To: jslint_com@yahoogroups.com
Subject: Re: [jslint] JSLint doesn't check if global variables are used.

You're right, of course, but even a library should avoid polluting the global
names space any more than necessary. I prefer to have all the library's
functions wrapped up in a single object, e.g.:

var MyLib = {
myFirstFunction : function () { ...},
mySecondFunction : function () { ...}, ,,,

};

Usually, the library will refer to itself at least once, obviating need there
for an /*external */ tag.

M.

________________________________
From: Jakob Kruse <kruse@...>
To: jslint_com@yahoogroups.com
Sent: Friday, May 1, 2009 1:24:47 PM
Subject: RE: [jslint] JSLint doesn't check if global variables are used.

Actually, that is very common. The purpose of most libraries is to declare
global variables for use elsewhere.

/Jakob

From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On Behalf
Of Michael Lorton
Sent: 1. maj 2009 18:47
To: jslint_com@yahoogroups.com
Subject: Re: [jslint] JSLint doesn't check if global variables are used.

The /*global */ tag solves the reverse problem: how tell if a variable used here
is declared elsewhere.

Perhaps we need a /*external */ tag that asserts a variable declared here is
used elsewhere. Personally, I would oppose it (mildly): if you aren't using it
here, why are you declaring it here, hmmm?

M.

________________________________
From: pauanyu <pcxunlimited@...>
To: jslint_com@yahoogroups.com
Sent: Friday, May 1, 2009 9:35:54 AM
Subject: Re: [jslint] JSLint doesn't check if global variables are used.

--- In jslint_com@yahoogroups.com, Michael Lorton <mlorton@...> wrote:
>
> In a formal sense, it's a bug, but how could it be fixed? A global variable
might be used by a different script, or by a bit of Javascript in an event
handler, even by Flash. There's no way to tell if one is never used.
>
> Another reason that Global Variables Suck.
>
> M.

As to your first point.. JSLint supports the /*global */ construct for global
variables defined elsewhere.

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

Yahoo! Groups Links

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

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

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

Yahoo! Groups Links

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

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

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

Yahoo! Groups Links

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


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

--- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@...> wrote:
>
> Yes, really. I fail to see why I would want to reference the global from
within its own declaration?
>
> That said, this discussion has gotten quite a bit off track. The only possible
purpose of declaring a global variable/function/object/whatever is so that it
can be accessed globally â€" from everywhere, and in particular, from elsewhere.
I find the current behavior of JSLint (not forcing me to declare globals twice
for clarity) to be correct. Declaring a global in some file and not using it in
that file (but possibly in every other file loaded) should not result in errors
or warnings.
>
> /Jakob
>

I agree, but the idea was to be more of a helpful hint. If you declare a
variable but don't use it, JSLint doesn't throw an error. Instead, it lists the
Unused variables in the useful summary at the bottom.

Although it would be great to have this same helpful hint with global variables,
it's been shown in this thread that such a system would almost certainly be
needlessly complex, without very much gain.

Internet Explorer has a window.execScript() method that basically does
the same thing as eval(), except that it always executes scripts in
the global scope:

http://msdn.microsoft.com/en-us/library/ms536420(VS.85).aspx

Shouldn't jslint flag this as "evil", too?


   - Conrad

--- In jslint_com@yahoogroups.com, "christian.wirkus" <christian.wirkus@...>
wrote:
>
> Hello!
> I think really neat would be something that generates the
> jslint-options-string (/*jslint ... */).

Interesting idea.

http://www.JSLint.com/index.html now provides assistance in building /*jslint*/
and /*global*/ comments.

The JSLint.com page looks ok on the minority browsers, but it looks lousy on
IE8. The vertical spacing is off, the fieldsets bleed, and the buttons are
wrong.

If you are at Microsoft, could you please ask the IE team to look into this?

Thanks.

--- In jslint_com@yahoogroups.com, "crlender" <crlender@...> wrote:
>
> Internet Explorer has a window.execScript() method that basically does
> the same thing as eval(), except that it always executes scripts in
> the global scope:
>
> http://msdn.microsoft.com/en-us/library/ms536420(VS.85).aspx
>
> Shouldn't jslint flag this as "evil", too?
>
>
>   - Conrad
>

I had a post on this last year: 
http://tech.groups.yahoo.com/group/jslint_com/message/93

There is something in the fulljslint.js code for this, but I couldn't get it to
trigger with the online check.

     if (!option.evil) {
	 if (left.value === 'eval' || left.value === 'Function' ||
		 left.value === 'execScript') {
	     warning("eval is evil.", left);

/*jslint browser: true*/ window.onload = function () {
document.getElementById("hello").appendChild(document.createTextNode("world"));
};

gives me:

*Error:*

*Implied global:* window *2*


Why does Assume a browser option allow document, but not window?


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

--- In jslint_com@yahoogroups.com, Arthur Blake <arthur.blake@...> wrote:
> Why does Assume a browser option allow document, but not window?

There is a post that mentioned it:
http://tech.groups.yahoo.com/group/jslint_com/message/475

In Javascript there is this global object hanging around everywhere, without
having a name to rely on; and in browsers it may appear with so many names
(window, parent, self), I guess it's not healthy to allow a special one.

Just stick with a single one and add it to your globals:
/*global window */

OK.. my bad.  I remember seeing that earlier thread, but for some reason
didn't connect the dots.
It seems a little weird that window isn't assumed when 'assume a browser' is
checked because it is one of the variables that is so frequently used in a
browser (maybe the point is that it shouldn't be so frequently used...)

On Thu, May 7, 2009 at 11:58 AM, christian.wirkus <
christian.wirkus@...> wrote:

>
>
> --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>, Arthur
> Blake <arthur.blake@...> wrote:
> > Why does Assume a browser option allow document, but not window?
>
> There is a post that mentioned it:
> http://tech.groups.yahoo.com/group/jslint_com/message/475
>
> In Javascript there is this global object hanging around everywhere,
> without having a name to rely on; and in browsers it may appear with so many
> names (window, parent, self), I guess it's not healthy to allow a special
> one.
>
> Just stick with a single one and add it to your globals:
> /*global window */
>
>
>


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

--- In jslint_com@yahoogroups.com, Arthur Blake <arthur.blake@...> wrote:
>
> /*jslint browser: true*/ window.onload = function () {
>
document.getElementById("hello").appendChild(document.createTextNode("world"));
> };

Write

     onload = function (e) {...};

instead. The window is superfluous.

> Why does Assume a browser option allow document, but not window?

Because global variables are evil, and window is the container of all global
variables. Dependence on global variables introduces unreliability, insecurity,
and weakness. You don't want superfluous badness in your code, do you?

On Tue, May 5, 2009 at 9:47 AM, pauanyu <pcxunlimited@...> wrote:

>   I see; thank you. Another question, why use:
> if (typeof console === 'object') {
>
> Instead of:
> if (console instanceof Object) {
>
> ?
>
> As far as I know, if "console" is null, typeof will return 'object', which
> would break the first code.
>
>



typeof will always return a string result, hence you have a guarantee you'll
get something to test against, on the other hand when testing with:

if (console instanceof Object) {

if console isn't declared you'll get a ReferenceError when trying to use
instanceof. You likely won't have problems on firefox w/ firebug which has
the console declared.


--
Marcel Duran


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

Try this:

addEventListener("load", function (event) {}, false);

--- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:

> addEventListener("load", function (event) {}, false);

Thanks. Please let me know if you find more of those.

There is a Fifth Edition of the ECMAScript standard in the works.

http://www.ecma-international.org/news/PressReleases/PR_Ecma_finalises_major_rev\
ision_of_ECMAScript.htm

It is the first revision of the standard that defines JavaScript in ten years.
It contains some syntactic improvements, such as tolerance of reserved words in
the dot notation and in object literals, and tolerance of trailing commas in
object literals.

These and other improvements will not be reflected in JSLint for the time being.
Most of the goodness of the Fifth Edition can be obtained with the old syntax.
It will be years before the Fifth Edition fully replaces the Third Edition, so
for most purposes it will be wise to stick with the restricted Third Edition
syntax.

The only exception is the "use strict"; pragma which is recognized by JSLint
now, and which can be demanded by an option. Over time I may add more options
requiring or allowing Fifth Edition features, but not now, and not soon.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> The only exception is the "use strict"; pragma which is recognized by JSLint
now, and which can be demanded by an option. Over time I may add more options
requiring or allowing Fifth Edition features, but not now, and not soon.
>

Sorry if this is a little off-topic, but I can't seem to find anywhere that
explains exactly what "use strict"; does. Oh, sure, there's the actual
specification, but it's noticeably... dense.

I'm current testing JsLint on our source code, and it displays quite a lot
of interesting warnings, even though I don't always agree with them.
For example, I get the following error:
Lint at line 14 character 38: Expected '{' and instead saw 'return'.
if(typeof(idOrObject)!='string') return idOrObject;

I see the point in the parser, since it expects:
if(typeof(idOrObject)!='string') {return idOrObject;}

but in my opinion, this is not an error.


I'd like to integrate JsLint into our build system, which is Nant based (
http://nant.sf.net).

For the reports, I need some XML output.
Since the rhino's version contains exactly what we need, I just call JsLint
with:

java -jar js.jar rhino.js source.js

where js.jar comes from the Rhino package:
http://www.mozilla.org/rhino/download.html

However, I'm not entirely satisfied with the reporting, since it doesn't
output the unused and unexpected global variables.
The unused variables will help me clean the useless declarations.
The unexpected global variables will help me fix the bad scopes (like for
(j=0;...) when var j is missing).

How could the Rhino script report the unused and unexpected global variables
?

JC


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

--- In jslint_com@yahoogroups.com, Jean-Charles Meyrignac <jcmeyrignac@...>
wrote:
>
> How could the Rhino script report the unused and unexpected global variables
>

From jslint commmented code:

"You can request a Function Report, which shows all of the functions and the
parameters and vars that they use. This can be used to find implied global
variables and other problems. The report is in HTML and can be inserted in an
HTML <body>.

var myReport = JSLINT.report(limited);

If limited is true, then the report will be limited to only errors."

I think you can integrate the report call in your rhino script.

Regards,
Alberto

There was a good talk at Google about the language changes.

<http://www.youtube.com/watch?v=Kq4FpMe6cRs>

IE7 won't execute this:

<script type="application/javascript">
alert();
</script>

The other browsers don't have a problem with it, but IE chokes. It's okay with:

<script type="text/javascript">
alert();
</script>

I'm not sure whether you want to consider this a bug or not, since it's clearly
a problem with IE; but it's worth consideration.

--- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:
>
> IE7 won't execute this:
>
> <script type="application/javascript">
> alert();
> </script>
>
> The other browsers don't have a problem with it, but IE chokes. It's okay
with:
>
> <script type="text/javascript">
> alert();
> </script>
>
> I'm not sure whether you want to consider this a bug or not, since
> it's clearly a problem with IE; but it's worth consideration.

I recommend leaving out the type attribute entirely. All browsers always do the
right thing when it is missing. Some of them fail, as you demonstrated, when it
is present.

Should JSLint complain about the type attribute?

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> I recommend leaving out the type attribute entirely. All browsers always do
the right thing when it is missing. Some of them fail, as you demonstrated, when
it is present.
>
> Should JSLint complain about the type attribute?
>

JSLint complains about the type property when used on a <script> tag that also
has the src attribute, but doesn't complain when you put the type property on a
<script> tag that doesn't have the src attribute.

Personally, I agree with you, but unfortunately the type attribute is necessary
for validation with the W3C, so not everybody will be so willing to get rid of
the type attribute.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> There was a good talk at Google about the language changes.
>
> <http://www.youtube.com/watch?v=Kq4FpMe6cRs>
>

Very nice. Thanks for posting; it answered some of my questions.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> There was a good talk at Google about the language changes.
>
> <http://www.youtube.com/watch?v=Kq4FpMe6cRs>
>

I've bad feeling about this. The talk is nice in a sense of giving an idea about
changes to come. But there is a feature, that once introduced, will be for sure
a big gamechanger for many people.

I'm talking about Object.freeze function (and its companions Object.seal and
Object.preventExtensions).

The future looks bleak, because once introduced into language (and once the
language spreads to all major browsers) the unavoidable ice age will start.
Maybe I'm overreacting here, but I've had stared at 'sealed' or 'private'
keyword cursing helplessly many times.

The idea of protection of object state is good in theory but lacks in
application. Authors will never anticipate all possible uses of their creations.
Javascript is now a 'fair use' language - if one wants to tinker with others
stuff, one is free to do so. Not anymore once Ecmascript5 hits the market.

Object.{freeze,seal,preventExtensions} are one way road. I just know that
everyone will abuse the hell out of them. And those who would like to reuse code
will have to resort to hacks - once freezed, object cannot be unfreezed. Combine
this with default values of [[Writable]], [[Enumerable]], [[Configurable]]
attributes for properties which are false!

The whole thing is just an injection of "DRM for the code" in a place, that as
for now is free from it.

Citation found on internet: "I see a name of another plugin for Firefox -
Object.unfreeze"

I'd call it 'Object.melt' :)

What are your thoughts about this?

Would it be possible to instead validate the necessary presence of the type
attribute with an empty value.  That way no value is supplied in accordance with
browser processing of JS and the attribute is still supplied for HTML
validation.

--- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
> >
> > I recommend leaving out the type attribute entirely. All browsers always do
the right thing when it is missing. Some of them fail, as you demonstrated, when
it is present.
> >
> > Should JSLint complain about the type attribute?
> >
>
> JSLint complains about the type property when used on a <script> tag that also
has the src attribute, but doesn't complain when you put the type property on a
<script> tag that doesn't have the src attribute.
>
> Personally, I agree with you, but unfortunately the type attribute is
necessary for validation with the W3C, so not everybody will be so willing to
get rid of the type attribute.
>

There should be an option to allow

var foo = "Lorem \
ipsum \
dolor";

because IE, Fx, Opera, and Safari support it, and ECMAScript 5 will allow it
officially.

Overloading a language is bad. You're right. But this feature looks really
really good. And languages that don't change are dead.

And what do you want to do? Include a library and change its properties?
I don't think that's a good idea. If the library changes, your augmenting will
probably fail or cause trouble; the defined interfaces of that library on the
other hand probably won't change.

Or we write a library or game of our own. The user who includes it, might
include three other libraries as well. And he might not have checked, what the
code of these look like.
Better he gets an exception, as soon as there are interferences; and not letting
things augment or change silently until one augmentation some time after
including everything causes a weird bug.

Also: I could create an object of constants; I could just look at the objects
definition to know what is in there. And what I need to change.
I don't need to trace down where the properties where changed because one of my
coworkers (or myself in sudden insanity) thought it a neat container for some
stuff he just needs to store somewhere for a little while.

var all_my_constants = {
    "ajax_news_url" : "...",
    ...
};

Christian



--- In jslint_com@yahoogroups.com, "iamonlyhereforpipes"
<iamonlyhereforpipes@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
> >
> > There was a good talk at Google about the language changes.
> >
> > <http://www.youtube.com/watch?v=Kq4FpMe6cRs>
> >
>
> I've bad feeling about this. The talk is nice in a sense of giving an idea
about changes to come. But there is a feature, that once introduced, will be for
sure a big gamechanger for many people.
>
> I'm talking about Object.freeze function (and its companions Object.seal and
Object.preventExtensions).
>
> The future looks bleak, because once introduced into language (and once the
language spreads to all major browsers) the unavoidable ice age will start.
Maybe I'm overreacting here, but I've had stared at 'sealed' or 'private'
keyword cursing helplessly many times.
>
> The idea of protection of object state is good in theory but lacks in
application. Authors will never anticipate all possible uses of their creations.
Javascript is now a 'fair use' language - if one wants to tinker with others
stuff, one is free to do so. Not anymore once Ecmascript5 hits the market.
>
> Object.{freeze,seal,preventExtensions} are one way road. I just know that
everyone will abuse the hell out of them. And those who would like to reuse code
will have to resort to hacks - once freezed, object cannot be unfreezed. Combine
this with default values of [[Writable]], [[Enumerable]], [[Configurable]]
attributes for properties which are false!
>
> The whole thing is just an injection of "DRM for the code" in a place, that as
for now is free from it.
>
> Citation found on internet: "I see a name of another plugin for Firefox -
Object.unfreeze"
>
> I'd call it 'Object.melt' :)
>
> What are your thoughts about this?
>