On 1/15/11, SteveYoungGoogle wrote:
> Well done! This looks like it will be *the* resource for people
> wanting to learn JavaScript.
>
Interactive discussion is a great way to learn. Good communication can
go a long way towards facilitating clearer discussions
http://www.faqs.org/rfcs/rfc1855.html
On Sat, Jan 15, 2011 at 5:15 PM, And Clover wrote:
> If you really want to make your code idiot-resistant, you still don't
> have to move loop `var`s all the way to the top of function. This:
>
> function doSomething(things) {
> // Loop that does something
> var i, thing;
>
On Jan 15, 2011, at 5:27 PM, Michael Haufe (TNO) wrote:
> #1 - function(){ WScript.Echo("foo") }();
> #2 - (function(){ WScript.Echo("foo") }());
> #3 - (function(){ WScript.Echo("foo") })();
>
> #1 is an error. #2 and #3 both work.
Maybe he suggests #2 exactly because #1 is an error... that
On Sat, 2011-01-15 at 12:39 +0100, Peter van der Zee wrote:
> If all variables are declared at the top, there's no risk at all of
anyone thinking variables in the loop are bound to "a block scope of
that loop"
If you really want to make your code idiot-resistant, you still don't
have to move loop
On Jan 15, 2011, at 2:49 PM, Diego Perini wrote:
> wrote:
>> #1 - function(){ WScript.Echo("foo") }();
>> #2 - (function(){ WScript.Echo("foo") }());
>> #3 - (function(){ WScript.Echo("foo") })();
>>
>> #1 is an error. #2 and #3 both work.
>>
>> If I type "foo" or if I type ("foo") they are se
On Sat, Jan 15, 2011 at 11:27 PM, Michael Haufe (TNO)
wrote:
> #1 - function(){ WScript.Echo("foo") }();
> #2 - (function(){ WScript.Echo("foo") }());
> #3 - (function(){ WScript.Echo("foo") })();
>
> #1 is an error. #2 and #3 both work.
>
> If I type "foo" or if I type ("foo") they are semantical
#1 - function(){ WScript.Echo("foo") }();
#2 - (function(){ WScript.Echo("foo") }());
#3 - (function(){ WScript.Echo("foo") })();
#1 is an error. #2 and #3 both work.
If I type "foo" or if I type ("foo") they are semantically the same
thing. same as if I type 1 vs (1), etc.
The fact that "functio
On Jan 15, 2:30 pm, Bill Heaton wrote:
> I am curious if anyone can give me insight why the nesting of the function to
> be immediately invoked should be completely contained within parenthesis ( //
> func () ); versus parenthesis + parenthesis ( // func )();
>
> I do not get why the parenthesi
Thanks for the kind words. We really appreciate it.
Asen & I started JSMentors.com specifically to provide a place where
developers of all skill levels can share ideas and get support without fear
of having their questions or feedback diminished. So far, it's worked great.
Many of the same top-lev
On Fri, Jan 14, 2011 at 10:42 AM, Peter van der Zee wrote:
> Crockford updated his tool (jslint) recently (1). I'm not really happy with
> enforcing some of the options he has enforced, but that's how it is. If you
> don't like it, you can always fall back to http://jshint.com/ which is
> basicall
> It looks to me that primitives has methods and properties.
Actually, what it does is automagically convert the primitives to
their object counterparts, run the functions, and then convert back to
a primitive.
Angus Croll wrote a blog post about it:
http://javascriptweblog.wordpress.com/2010/09/2
I am curious if anyone can give me insight why the nesting of the function to
be immediately invoked should be completely contained within parenthesis ( //
func () ); versus parenthesis + parenthesis ( // func )();
I do not get why the parenthesis (and arguments if needed) would be better
plac
2011/1/15 Vishal Singh :
> I’m taking a guess here, trying to justify this and would appreciate
> feedback in my thinking. Since new has to set up the prototype chain, it
> would necessarily have to return an object since primitives do not have
> properties and methods. Does this sound right?
It
On 13 Jan 2011 23:03, "Joel Dart" wrote:
>Why? Well, simply because that's how the specification says it should be.
I’m taking a guess here, trying to justify this and would appreciate
feedback in my thinking. Since new has to set up the prototype chain, it
would necessarily have to return
Well done! This looks like it will be *the* resource for people
wanting to learn JavaScript.
I have been a regular reader at c.l.j. for about two years now. I
stopped asking questions there over a year ago however, because of the
bad manners and rudeness of some of the regulars there and the stupi
I have found the following article by ben cherry to be the most useful
way to detect unintended globals and also a justification to use var
for all global variables.
http://www.adequatelygood.com/2010/2/Finding-Improper-JavaScript-Globals?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+
Only using one 'var' is a best practice to prevent problems related to
'variable hoisting'
This link provides a good explanation/video:
http://net.tutsplus.com/tutorials/javascript-ajax/quick-tip-javascript-hoisting-explained/
Not sure about the online tool, but I assume you can download jslint
a
On Sat, 15 Jan 2011 17:38:24 +0100, Michael Haufe (TNO)
wrote:
Here is a contrived example, but with some imagination I think some
utility could be applied to this.
var a = 6
var b = Number(6)
That's the same as "a".
var c = new Number(6)
Number.prototype.valueOf = function(){
throw
On Jan 14, 9:15 pm, Joel Dart wrote:
> Creating Number objects is pretty much useless. If you ever need an *object*
> that stores a
> number value, you can just create a custom object yourself and store the
> number value as
> a property - it's probably also better Object Oriented modelling than
On Sat, 15 Jan 2011 04:15:52 +0100, Joel Dart wrote:
Number constructor has to exist to give access to the prototype which I
agree isn't as useful in itself. However, augmenting Array has several
interesting uses. The more I think about it, the more I see that the
constructors and access
disagree in every your point :)
1. if your variable name is "thing" in both cases, then you are talking
about the "thing", it is the same subject, so either your naming is wrong
or this is semantically correct to define it once.
2. your copy paste problem is can't be seriously considered.
1
On Sat, Jan 15, 2011 at 12:25 PM, And Clover wrote:
> On Fri, 2011-01-14 at 10:12 -0800, cancel bubble wrote:
> > I understand that it's good practice to declare all your vars at the
> top of
> your function
>
> I disagree. This is one part of Crockford Dogma I think is badly
> mistaken. It's a h
On Fri, 2011-01-14 at 16:24 -0800, foldi wrote:
> I have an upcoming project that involves multiple timers and need a
> response if someone asks, "Where's the missing time?".
Any long-running script or plugin, even on another page in the same
browser, can cause timers to stop firing for extended p
On Fri, 2011-01-14 at 10:12 -0800, cancel bubble wrote:
> I understand that it's good practice to declare all your vars at the
top of
your function
I disagree. This is one part of Crockford Dogma I think is badly
mistaken. It's a habit from other languages that is, IMO, actively
unhelpful in JS.
2011/1/14 Gary Katsevman :
> The reason why he doesn't like putting the var in the for loops has to
> do with variable hoisting and non-block scope in javascript.
>[code]
> He would rather people define the variable outside of the for loop so
> that people realize that the variable is still ava
25 matches
Mail list logo
