Douglas Crockford

19,210 followers -

_ __ ___ ____ _____ In the Twenty First Century!

19,210 followers

About

Douglas's interests

JSLint

704 Members

Ask to join

Douglas's posts

Post has attachment

Douglas Crockford

Owner

JSLint Discussion

Should JSLint require that 'export' and 'import' be at the top of the file?

26 votes

votes visible to Public

62%

yes

38%

Brian McMillin: Perhaps the actual issue boils down to this decision:
Do you feel the exports is part of the program or is it to be viewed as primarily documentation?
I had not even considered the possibility that its primary purpose would follow a strict top-down, declare-before-use policy. I.e., strictly from the compiler's viewpoint.
I prefer the top of the program or module to describe its purpose, what it needs/expects to be able to operate, and what it will provide to me when it is done.
I especially do not want to have to wade through the cruft in the middle just to see the names of the results that I can ask for.
Consider it sort of an interface section, to be filled in later.
-----
Actually, upon further consideration I think I would argue that the exports is the most important property of the module and should be placed first.
Therefore, I would suggest: thinking in terms of an interface section describing what this module can provide to the user, (exports), what this module will require in the way of resources to accomplish its goal (imports), and then the rest of the code (essentially the implementation section).

Alex Babis: +Brian McMillin I hadn't considered that option. I've been exporting one object in my files because it most closely matches the Revealing Module pattern. I like how listing the interface at the top would improve readability. I dislike how you would have to write every property name twice.

Ben Quarmby: I've retracted my vote. I just don't have enough experience writing ES6 modules to weigh in on best practice. Given there are no stable implementations (sans transpilers), I'm not convinced there is enough evidence to support either option at this juncture.

Post has attachment

Douglas Crockford

Public

I will be headlining at Midwest JS in Minneapolis.

Midwest JS

midwestjs.com

Post has attachment

Douglas Crockford

Public

http://www.dotnetrocks.com/?show=1288

.NET Rocks! vNext

dotnetrocks.com

Post has attachment

Douglas Crockford

Public

JavaScript's function scope rule says that an inner function can implicitly see the variables of outer functions and must explicitly declare its own variables.

|   function javascript() {
|       var a = 0;
|       function inner() {
|           var b = a;
|       }
|   }

So imagine another language that does it the other way. There is no 'var' statement because variable declaration is implicit. But to see an outer variable, you must first use a 'see' declaration.

|   function another() {
|       a = 0;
|       function inner() {
|           see a;
|           b = a;
|       }
|   }

Any program that could be written JavaScript could also be written in the another language. The difference is in programmer convenience (very low value) and error avoidance (very high value).

Which language would be better at avoiding declaration and scope errors?

248 votes

votes visible to Public

33%

JavaScript

47%

Another

21%

Neither has a significant advantage

Joe Gibbs Politz: I'm confused by your first comment – did I use two 'a's in some scope?

In my own code, I'm so used to closing over variables from years of using functional helpers like map and filter that this would be a significant inconvenience.

The mistakes I can think of involve the combination of capture and assignment. When closing over a variable that is assigned to (whether inside or outside the function), there's more that can go wrong since the sharing of mutations between scopes is tricky to puzzle out. In JS, there's a canonical example of a for-loop that registers a callback on each iteration that closes over the loop variable – all the created callbacks refer to the same variable and thus behave the same, when that's not what the programmer likely intended.

So "see" is intriguing to me in the case of variables that are intended to change, which may not have been intended to be captured. In those cases, I suspect a red flag in the syntax for "hey, action-at-a-distance is happening here" could be really useful.

Design question: What's the error message for forgetting a "see", and what are useful ways for programmers to respond to it? Will they all just add "see" and move on?

Douglas Crockford: You had
see a;
var a;
in the same function. That should not be allowed.

I appreciate that there are patterns we get used to. But I want to look past those in hopes of finding better patterns.

Used-to arguments were used as arguments against structured programming and object oriented programming, stalling progress by a generation.

I am used to implicit closure too, but I want to explore the possibility that there might be stronger patterns.

Joe Gibbs Politz: Yup, my point with the see/var example was that the "see" was unnecessary/not meaningful there, underscoring the benefits of having explicit declarations.

Agreed on "used-to" arguments.

My position is:

1. I don't think "see" adds much value for capture of immutable variables, because I don't believe that capturing immutable variables is the source of many errors. (What's an example of this happening?)

2. I do think it could add value for mutable variables, where I think capture is more fraught.

Douglas Crockford

Public

10w

Edward Snowden is an American Hero.

It is time that we bring him home.

Douglas Crockford

Public

you

How much do you make? Have you ever contemplated suicide? Are you now or have you ever been... ? Are you aware of the fact... ? I have here before me.... Electrical information devices for universal, tyrannical womb-to-tomb surveillance are causing a very serious dilemma between our claim to privacy and the community's need to know. The older, traditional ideas of private, isolated thoughts and actions--the patterns of mechanistic technologies--are very seriously threatened by new methods of instantaneous electric information retrieval, by the electrically computerized dossier bank--that one big gossip column that is unforgiving, unforgetful and from which there is no redemption, no erasure of early "mistakes." We have already reached a point where remedial control, born out of knowledge of media and their total effects on all of us, must be exerted. How shall the new environment be programmed now that we have become so involved with each other, now that all of us have become the unwitting work force for social change? What's that buzzzzzzzzzzzzzzzzzzing?

[Marshall McLuhan, The Medium Is The Massage, 1967]