views:

125

answers:

3

Hi there,

I've decided to get used to using Javascript as my server sided (I'm using Node.js) language to setup a webserver, create server deamons and a lot more. This is a rather big project, which means that I have to get used to the language and get myself an optimal setup before actually starting to avoid overhead and unneeded hassle.

I have been looking for sources that'd explain the basics of functional programming in big projects. Unfortunately, most sources talk only about basic Javascript meant for simple tricks in a browser.

Two helpful links that explained how object creation works in Javascript were http://howtonode.org/object-graphs and http://howtonode.org/object-graphs-2.

In the end, it seems most wise to create an object like:

function MyObject(constructorMemberOne, constructorMemberTwo) {
   this.constructorMemberOne = constructorMemberOne;
   this.constructorMemberTwo = constructorMembertwo;
   this.doSomething = function doSomething() {
       //
   }
}

Now, I'm looking for a complete Javascript language reference. So far, https://developer.mozilla.org/en/JavaScript/Reference seems to be most complete.

Q1: is this the recommended ECMAScript language reference? I'm asking mostly because it's sourced by a company that's mostly working in the browser industry, yet Javascript is not just there for browsers -- maybe there are sources that I'm unaware of.

Secondly, I'm used to creating a new file for every class I create where the file name represents the name of the class. Q2: Is this recommended practice in Javascript (V8, Node.js) too? How would one "import" this class?

This "importing" leads me to my confusingness about Node.js's "require". I know it's not the same. Require basically loads another file which then has it's own namespace, meaning that it's variables are out of the scope of the file that's requireing this file. For my classes however, I want to have methods that are available to the class that is "importing" (quotes as I am not sure whether this is even possible) this class. Eg.:

var utils = require("utils/MainUtils.js");
utils.doSomething();

As far as I know, this doSomething() method is only available if it was set like:

function MainUtils() {
   exports.doSomething = function doSomething() {
      //
   }
}

Q3: Is that correct? Doesn't that seem quite abnormal?

Q4: Are there any other blogs or resources that are helpful in getting my setup working, like howtonode.org?

Finally, Q5: have there been any efforts into making all this inheritance, object creation, project structure, namespacing etc. easier for big projects? Any libraries or something for this purpose?

Hopefully my questions are clear. Any help is appreciated. Thanks.

+2  A: 

is this the recommended ECMAScript language reference?

Well the official ECMAScript language reference is the ECMA-262 itself. But unfortunately this is completely unreadable even by the standards of standards documents.

ECMA do not produce any materials aimed at end-programmers and there's no one tutorial considered “best”. The MDC link looks decent, at least. (Most JavaScript tutorials are absolutely horrible and full of errors. Which is partly JavaScript's fault for having so many... quirky... features, but still.)

In the end, it seems most wise to create an object like:

There is unfortunately no widely-accepted-‘best’ way to implement a class/instance system in JavaScript. A lot of frameworks have their own systems, or you can brew your own. Your example code creates a new instance of each method for each object instance, which you might consider suboptimal compared to JS's native prototyping. (Normally this approach is used with a var that= this in the closure to avoid this-binding problems in callback code.) You would also need to exercise care in how you create subclasses and initialise them in the constructors.

See this question for a discussion on approaches to class/instance in JS.

I'm used to creating a new file for every class I create

Yeah, that's a Java wart you shouldn't bring to JS.

Keep your source files in manageable chunks of related classes and functions. Sometimes that will be one public class per file, more often it won't be.

How would one "import" this class?

JS itself has no native import functionality. In browsers you do it by inserting <script> tags or eval​ing code fetched by XMLHttpRequest, and have to take care of keeping variables in separate namespaces manually. In Node.js and other places where you're working with CommonJS, you use modules and require().

Is that correct?

Yes.

Doesn't that seem quite abnormal?

I don't think so. It's similar to other scripting languages, where it proves very useful. It's only really Java that forces you to wrap up a compilation unit into a single class.

bobince
Thanks, I'm not sure about the files though. I think having one file for every class makes the structure much easier to understand. You said I should keep it in manageable chunks, but what defines a manageable chunk? One class per file seems a good definition that doesn't cause a lot of confusion, but it is not recommended? Is it even possible at all? I guess one would have to require() every class if separated per file? Also, do you happen to know more sources I can look at (Q4, Q5)?
Tom
Also, what do you think about http://www.prototypejs.org/learn/class-inheritance ? Are there more of such frameworks? Is any of them widely used?
Tom
Prototype's “old syntax” I wouldn't consider because of the nastiness of using an actual `new Person` instance as a prototype. The “new syntax” is OK, I guess, but it kind of hides what JS is really doing with prototypes, and the implementation is rather heavyweight, adding an extra wrapper method for every class method that has the first argument `$super` (yes, it has to be that exact name, and it does this check using function decomposition... eek, that's a nasty hack).
bobince
Note that JavaScript is distinct from ECMAScript. [JavaScript](http://en.wikipedia.org/wiki/Javascript) is maintained by Mozilla (originally Netscape) as a language that complies with ECMAScript and adds extensions on it. It's popular enough that it has become a synonym in the vernacular, but technically IE, Chrome, and other non-Mozilla browsers don't actually interpret Javascript. They may implement some of its extensions. The MDC reference is pretty good, in particular noting items that are extensions to the standard.
intuited
+1  A: 

I came up with the following after reading a book called Pro Javascript Design Patterns. However, I've been told that it's not good to think like this (private, public, static, etc.) in Javascript:

var SomeClass = (function() {
    this.prototype.publicStaticMember = "this is a public static variable",

    this.prototype.publicStaticMethod = function() {
        return "this is a public method: cannot access private members/methods, but can access privileged and public members/methods";
    }

    var privateStaticMember = "this is a private static variable";

    function privateStaticMethod() {
        return "this is a private static method: can only access private members/methods";
    }

    //instance part
    return function() {
        this.publicInstanceMember = "this is a public instance variable";

        var privateInstanceMember = "this is a private instance variable";

        this.publicInstanceMethod = function() {
            return "this is a privileged method: can access both public and private members/methods";
        }

        var privateInstanceMethod = function() {
            return "this is a private method: can access both public and private members/methods but is private";
        }
    }
})();

It'd be instantiated like this:

var someInstance = new SomeClass().("param1", "param2");

Any comments? Should I read an other book?

Tom