Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
nodejs
Home
+ new post
About this group
Join this group
Message from discussion should issue a warning when "strict mode"; is missing
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
AJ ONeal  
View profile  
 More options Jan 22 2012, 10:57 pm
From: AJ ONeal <coola...@gmail.com>
Date: Sun, 22 Jan 2012 20:57:48 -0700
Local: Sun, Jan 22 2012 10:57 pm
Subject: Re: [nodejs] Re: should issue a warning when "strict mode"; is missing
Print | View thread | Show original | Report this message | Find messages by this author

*The Lose-Lose Case*
===

I'm not saying that, if there is absolutely no possible way to work around
the flaws inherent in the system, that you should not get the work done.

Rather, what I'm saying is that you should adhere to the rules first and
cater to the exceptions on a case by case basis.

I realize that test-driven development kind of trains your brain to
consider every possible edge-case (and a lot of people have that
pre-optimization mentality anyway), but...

*This is a 90 / 10 problem.*
===

What percentage of NodeJS developers use Octal?
What percentage of JavaScript *users* use Octal?

What percentage of JavaScript *users* don't realize that if they forget
`var` their variable becomes a global?

The question here isn't about the 1% that use these features, it's about
80% that get tripped up by simple newbie mistakes.

*With more power comes more responsibility*
===

I would rather cause disciplined devs like you and me a little grief here
and there than every single newbie that comes into JavaScript and NodeJS
suffer completely unintuitive silent errors and such.

If Octal is so important for the NodeJS devs, then add a core module for
the basic operations. But what about the users?

*It's about the user*
===

Do you see what I'm saying? *Application languages* - JavaScript, ruby,
python, etc - *are about abstraction. That is their purpose!*

Not wanting workarounds isn't "lazy". I'm pretty sure that if you have

> to replace well-written stuff that just works with "workarounds", this
> is a huge -1 on that change.

If it were well-written, it shouldn't have any issues in strict mode other
than the octal change.

> > (function () {
> >   "use strict";

> Without the indent. Please.

I'm okay with that. It just looks weird without the indent to me.
If I had seen some sort of precedent without the indent, I would have used
it that way.

> Globals are EVIL. BAD. RUDE. INCONSIDERATE. NASTY.

> > I can't believe I'm hearing support for globals!!

> I think you're exaggerating a lot here. What about, for example,
> "process"? Or what about logging?

I wish so bad that it were required instead.

It has caused me extra work (albeit minimal) to get some node / npm modules
to run in the browser because `process` is used.

> > I'm being sincere. I thought that everyone in the programming communities
> > had gotten the memo that globals and gotos are words you feel dirty
> inside
> > for using (except in the kernel where you use gotos to implement the
> > decorator pattern without the overhead of function calls - and the people
> > there are hopefully disciplined enough to not make severe design
> mistakes).

> Uh? So you're basically saying "globals aren't too bad, but they're
> sharp tools that can be used for nasty stuff, so drop them and use
> this wooden knife instead"? Yes, it sometimes is bad to use them, and
> yes, it's not what we should put on top of tutorials, but we
> definitely shouldn't discourage them that much.

I was saying that `goto` takes the place of the decorator pattern in C,
since C is a hardware language with a limited feature set, not an
application language with wonderful abstractions.

The kernel isn't an application. It has a different set of design patterns
than applications do.

Applications should not use globals.

> > Browser
> > ---
> > You don't need globals either. A TON of effort has gone in to making sure
> > that you can write modular JavaScript. Thanks to RequireJS, Pakmanager,
> and
> > Ender, you can install straight from npm into packed browser-safe code.

> What about JSONP? You need global functions for that, no?

Actually, for all modern browsers (including MSIE), JSONP is no longer
necessary.
Welcome CORS and XHR2. :-D

I'm not saying that, if there is absolutely no possible way to work around
the flaws inherent in the system, that you should not get the work done,
but that you should adhere to the rule first and cater to the exceptions on
a case by case basis.

(And actually, I've been considering writing a `window` module for the
browser that copies the properties that are actually part of `window`)

> > Octals
> > ---
> > I guess since a lot of people on this list work with c++ for native node
> > modules it makes sense.

> Uh... and e.g. working with the filesystem, too.

> > But JavaScript is a high-level language primarily used for interacting
> with
> > users.
> > If you want to use octals... USE C!

> Ah, right, Javascript doesn't belong on the server or so. You're sooo
> right.</scnr>

JavaScript is an application laguage. It works just as well on the server
as ruby or python - just a bit better because it handles JSON natively and
has a built-in event system.

> > Do you know how many times I've been bitten by parsing user input that
> had a
> > leading '0' and have scratched my head for too long trying to figure out
> > where the math had gone wrong? A lot! (but I'm getting better and
> > remembering to check for corner cases that strict mode can't protect me
> > from);

> Well then, sounds like you're using the wrong tools to parse user
> input. And like you're not reading documentation. E.g. parseInt only
> tries to determine the radix based on the input if you don't
> explicitely specify it.

That's exactly my point. I *want* an application language to hold my hand a
little (or at least be intuitive - there should be a parseOct and parseHex
- or do you have an argument or using a radix of 3 and 7 as well?).

If I wanted to have absolute full control I'd use C.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google