In the discussion here, the comments in the accepted answer suggest that I appro
ID: 646227 • Letter: I
Question
In the discussion here, the comments in the accepted answer suggest that I approach the given code from a functional perspective, which was new to me at the time. Wikipedia said, among other things, that FP "avoids state and mutable data", which includes according to the discussion global vars. Now, being that I am already pretty far along in my project I am not going to learn FP before I finish, but:
How is it possible to avoid global vars if, for instance, I have a UI whose entire functionality changes if a mousebutton is down? I have a number of things like this.
Why was there a strong negative reaction among some experienced coders to implementing FP in JS? When I brought up what seemed to me to be supportive comments by Crockford, people got even madder. Are there strong arguments against using fp in JS? What constitutes a "functional language" and why is JS "not it"?
Explanation / Answer
Please note: There is never an excuse for being a total douchebag. I am not justifying bad behavior on IRC but hopefully this will offer some perspective.
Avoiding global vars is easy. If I understand FP correctly however, the idea is to avoid generalized state altogether. This does not jive well with closure/event-driven UI work, IMO, which are two things JavaScript is very good at. You should of course, be careful to avoid letting state become overly generalized to the point where a wide variety of objects can be responsible for changing it. When tempted to make state completely global, you should be asking yourself if you shouldn't be creating a composite object of several smaller UI objects that owns responsibility for that state.
Crockford's done a lot of good work but we don't all revere him as some sort of god and I for one disagree with a lot of stuff he's declared "the bad parts" of JavaScript. I also find most of JSLint's default rules excessive, silly, and overly reflective of one developer's personal coding preferences. Function hoisting for instance, is fantastic. I love getting straight to the business logic in my apps at the top of my objects and callback functions and declaring the inlines below. FP itself seems overly procedural, IMO. Complex UI, which you don't see a lot of on Yahoo, is better served by a more loosely-coupled, event/messaging-driven paradigm in my experience. JS derives it's flexibility and power from closures and first-class functions. Not having any upper layers where state can be referenced isn't really a great fit with that, IMO.
Edit: Avoiding global vars
(function(){
var comboBoxesLoaded = false;
comboBoxesLoaded = UI.ComboBoxFactory.initiateComboBoxes();
//builds comboboxes and returns true
})()
alert(comboBoxesLoaded); //undefined error here.
Technically, you're not declaring a global var. comboBoxesLoaded is a state var scoped in an anonymous function but it's better to have a comboBox object that maintains its own state and also manages stuff like one (or several) comboBoxes loading in new data when another is changed.
All this does is avoid global namespace collisions, which is good, but you're still maintaining state in an overly general space where anything else you drop inside the anon function could hit it. (the idea behind this pattern is that you drop a ton of your code inside that anon function so you don't have to sweat blowing up other code you don't control by accidentally giving a global var the same name)
But it's stil better to let your combobox factory manage that state. It can listen to other objects to make changes but when you're certain you know only the factory is actually putting its hands on its own internal state vars you have one central point to go to when you're wondering why you're encountering an unexpected state at some point of breakage and the object itself can keep track of who it was listening to last.
Example of composite objects? That's getting into writing a small app territory. Maybe later.