Questionnaire:Big breaking change - method name changes lowerCamelCase, Yes or No?

Sep 17, 2011 at 12:02 PM

The method name of current linq.js is UpperCamelCase.
However, the standard naming convention of JavaScript is lowerCamelCase.
I think I made lowerCamelCase at the time of an initial design is big mistake.

It was announced BUILD that a JavaScript was chosen as one of the languages of WinRT.
Of course the place of the activity of JS including Node.js and MongoDB spreads out more and more.

I decided that I switched to lowerCamelCase as a breaking change.

How does it seem about this?
Tell the yes and no.

Sep 20, 2011 at 1:22 AM

Either way is fine with me...if I need to fix my code that doesn't look like a large issue.

Do you expect to release a new version anytime soon?

I find this project very useful. Thank you for your efforts.



Sep 24, 2011 at 2:17 PM

I'm very much in favor of the lowerCamelCase convention. Sure using UpperCamelCase makes it look more familiar to C# developers, but from the point of view of a pure JavaScript developer it looks very strange. And IDEs likes WebStorm by JetBrains which offer some form of code validation will complain about using constructor functions in a bad way, since UpperCamelCase is usually reserved for constructors. I actually thought about forking linq.js and converting all uppercase functions to lowercase, because it is a bit annoying.

By the way, while you are add it, please add semicolons to the function assignments. 

var Enumerable = function (getEnumerator) {
      this.GetEnumerator = getEnumerator;

But don't get me wrong, linq.js represents a stunning effort and it is the best LINQ implementation in JavaScript I have seen  so far. I really have to thank you for your efforts!

Sep 28, 2011 at 12:28 AM

Thank you for all of you.
If there is some request, please say.

By the way, when switch to lowerCamelCase,
it is necessary to change a method name.
For example, Do or Catch.
Therefore I want to add adjustment to a method name.

Do -> doAction
Catch -> catchError
Finally -> finallyDo
Return -> make
ToString -> toJoinedString
CascadeDepthFirst -> traverseDepthFirst
CascadeBreadthFirst -> traverseBreadthFirst
BufferWithCount -> buffer
MemoizeAll -> memoize

Is this all right for ToString?
Please say alternative plan.


My plannning schedule is
beta release in October, stable in December.

Sep 28, 2011 at 4:57 AM

@neuecc, thanks for all your great work!

If you are going to make a significant upgrade to the package, I strongly suggest that you put in a number of changes so that the library can be used with the Closure Compiler.  In my experience, using the Closure Compiler eliminates most of the overheads of using this library and takes away the performance penalty.

I'll find a place to upload my modified version of linq.js (which works with the Closure Compiler) for your reference!

Thanks a GREAT DEAL for such a fabulous piece of work!  It makes JavaScript much less painful to write!


Sep 28, 2011 at 5:02 AM

@neuecc, FYI, I have created an issue with an attached file (the modified linq.js) for your reference.  Thanks!

Dec 16, 2011 at 8:08 PM
Edited Dec 16, 2011 at 8:16 PM

Oh, god. Please no. I beg you.

Don't change to lowerCamel. It's so much more harder to read. 

MS's Reactive Extensions too features the dual methods of Enumerable in UpperCamel and they're got support for WinRT, WinPhone, Silverlight and .NET - they've gone out of the way to make sure it stays all the same. You have no idea how cool it is to combine Rx and Linqjs.

Please leave Enumerable like it is. It's perfect. Ignore the javascript purists. 


A great example would be Three.js (

var camera = new THREE.PerspectiveCamera(70, window.innerWidth / window.innerHeight, 1, 1000);

So much easier to read.

Jan 23, 2012 at 6:32 AM
asti0 wrote:

A great example would be Three.js (

var camera = new THREE.PerspectiveCamera(70, window.innerWidth / window.innerHeight, 1, 1000);

So much easier to read.

The above code is a constructor and such should be named with UpperCamelCasing according standard JavaScript naming conventions. Object members should be named with lowerCamelCasing which Three.js also follows if you have a look at the other source code:-)

This said, I am also in favor of following JavaScript naming conventions and use lowerCamelCasing which all other JS frameworks adhere to.

Feb 17, 2012 at 7:35 PM

+1 for following JavaScript conventions.  Also why do you want to rename toString?  This is not a reserved keywork.

Mar 20, 2012 at 5:20 PM

Latest RxJs release has made the change to lowerCamel.  +1 for Linq.js to do the same!


@gatapia:  toString is a method on the Object.prototype and, by convention, takes no arguments and converts the object into some sort of string representation.  IMO it would be a bit confusing to have toString() overloads on enumerables which do customizable string concatenation of the sequence.  I'm definitely in favor of renaming it to something different to avoid that confusion.

Mar 21, 2012 at 2:45 AM

+1 on camel case.

May 2, 2012 at 10:29 AM

Please NO. It just makes it harder to port code from C#.

May 2, 2012 at 9:52 PM

+1 for camelCase. It's always better to stick to language conventions rather than import different conventions from other languages. Even WinRT does this.

May 5, 2012 at 6:26 PM

+1 for camelCase.

Also, is there any way to shorten Enumerable.From(array)?  Seems wordy compared to other libraries like underscore.

May 8, 2012 at 5:41 PM
Edited May 8, 2012 at 5:43 PM


All +1 to change to javascript standard format are crazy!!!

How mutch code you wrote until now?

I think you wrote few lines...

I have an javascript app widely using linq.js And I hope no rewrite the code because some purist people think is not cool or javascript exact format.

Please do not change the different things, accept it. Be tolerant of it.


In the other hand... why waste your valuable time in this "stetic" question when you have a lot of ideas and work to do...

May 27, 2012 at 5:19 AM
Edited May 27, 2012 at 5:19 AM

Seems like HanniSullivan has captured the best of both worlds.  Why not alias the methods and offer both options?

Jun 22, 2012 at 7:05 PM

-1 as well. You gain absolutely nothing by making the change and will break TONS of code dependent on it. It may be the convention in JS, but the library is a mirror of LINQ and LINQ uses upper camel case, so why not keep to the LINQ convention?

Jul 16, 2012 at 3:00 PM

Strongly against changing to lowercase names, especially if it causes compatibility problems. It may not be "standard" JavaScript syntax, but it's at least familiar to .NET developers, who will be using the library anyway.

Jul 18, 2012 at 11:29 AM

Is linqjs only for .NET developers ?..... +1 for camelCase.