Thanks for your enthusiastic comment.

I think your idea with a “newClass” prefix is really great. It gives the compromised solution for our last discussion with Andreas Grech. It starts with small letter and it gives precise indication of the Class. Really nice.

Talking about performance warning, you are completely right. I will add it as the footnote to the article, together with advices of “new” prefix.

This is an excellent article explaining the pros of the factory pattern to simulate “classes”. I just have a couple notes.

First, if you do ever mix constructor functions with factory functions, then you can prefix your factory function names with new. For example, let’s assume I have two “classes” Person and Shape. Person is implemented using a constructor and Shape is implemented using a factory.

function Person(…) {…}
Person.prototype.foo = …

function newShape(…) {
return …
}

Then when you’re using them, it will be either “new Person()” or “newShape()”

Secondly, I am a huge personal fan of the factory style for creating objects, but it’s unfair to promote it without warning people of the performance costs. Each and every instance has it’s own copy of every function and a closure for each. This comes as a huge cost if you’re going to be making lots of these.

Anyway, overall a great article.

I think your first paragraph is exactly the place where our thoughts are going separate ways. The fundamental difference in views, at which we ground our arguments, pros and cons.

As I said, my main idea is that choosing only one factory and using the same conventions everywhere for the whole codebase is just a “MUST”. It shouldn’t matter “if there is more than developer working on the same library”. This is the reasons why I do not see “an uncommon sight to see ‘var p = new Person();’ and ‘var u = user();’” in the code. Having such mixin in your code, means that conventions are not used. And if such developers unable to stick to one format in their own code, how do you want them to stick to the global well-known conventions for the whole JavaScript?

Of course, you are totally right that we should stick to the common and well-known conventions, personally I think that too. The only reason I used PascalCase naming is to make the clear separation between Classes and function calls. In the case when more than one library is used, indeed, it might be better to use lowercase names for factory classes.

In that case, I presume that it’s not an uncommon sight to see ‘var p = new Person();’ and ‘var u = user();’ in your code. That’s why I suggested that you should keep to this well-known convention.

JavaScript is already a very messy language as it is…people mixing conventions will not help improving this mess.

Also, you said it yourself: “Should I use ‘new’ or without ‘new’ for this class”.
By keeping to a common, well-known convention, you can overcome this obstacle. Therefore, if a user sees that a function starts with a Capital letter, he knows that it must be invoked with the ‘new’ keyword.

As regards your last paragraph, I can’t really understand your point there. So you’re saying that it’s a good thing that a user is confused as to whether to use the ‘new’ keyword or not (“Hey, there is a function call, but no new. Hm, it starts with capital letter, why is that?”)? Why violate the Principle of least astonishment like that?

Make sense. But I will explain you my thoughts about camelCase and PascalCase.

Usually you are not using more then one factory inside your app/framework/lib. Also as soon as you start using one of them you try to stick to it, and to declare everything at the same way. First of all it keeps your code consistent and also it minimizes “the places, where it can go wrong”. That’s why I assume that in such code you will not see the mixing of different declarations, like “var user = User()” and “var thing = new Thing()”. This means, that you will not have to think “Should I use ‘new’ or without ‘new’ for this class” ?

Further I think that the person who was putting the basics for the app/framework/lib has consciously chosen such factory and he is the one, who is responsible for brining that info to others who are going to use it.

At the moment when you try to use camelCase for classes without “new”, you leave yourself completely without no awareness to distinguish the classes from the functions. Switching to another factory or library at a later moment can become much harder, since you can’t do it anymore based on the pattern like “=\s*[A-Z][^(]*\(” ( so “sed” or any other search and replace tooling will be of no use ). In this case you will have to do it manually or use some other more complex tricks.

For me personally, it’s important that the code at which I look, is expressive enough or at least has some hits. And this is exactly what code “var user = User()” is doing for me. It shows me “Hey, there is a function call, but no new. Hm, it starts with capital letter, why is that?”

When using those kinds of factory functions that create objects without the need of the ‘new’ keyword, you should ideally name them using camelCase rather than PascalCase.

So in your example, it would be like such:

var user = function(){ …

var user1 = user();

This is because capitalized function names are usually used to indicate that the function is a constructor and thus needs the ‘new’ keyword for invocation. Since JavaScript does not signal any form of warning when not using the ‘new’ keyword in places where it should have been used, using capitalized names is a way for such an indication.