5 ms·
On the other hand, it's quite convenient if you can't remember the exact name and it saves you a look-up e.g. quick_sort vs quicksort vs quickSort - either work
by okasaki 12y ago
On the other hand, it's quite convenient if you can't remember the exact name and it saves you a look-up e.g. quick_sort vs quicksort vs quickSort - either work
- nercury 12y agoI do not get it - what kind of "win" is it? For example, I know that PHP functions are case-insensitive, but we got to the point where we run linters to check if we used the same case as in declaration. Why not simply bake it in the compiler, especially when you HAVE a compiler?
- drewnoakes 12y agoPerhaps it's a reaction to the state of affairs in C++. In Java and C# there are pretty widely adhered to coding standards. It's quite hard to find libraries that don't have consistent public APIs with these standards, and those that differ are usually subject to rumblings on their mailing lists and issue trackers. In C++ there is no agreed upon standard. The standard library uses lower_train_case for all (public) types/members, and much 3rd party library code uses PascalCase and camelCase. The C++ standard library has fewer features than the Java/C#/Python standard libraries, and so you end up bringing more 3rd party code into non-trivial projects (in my experience). If this feature existed in C++, a codebase could be much more internally consistent. However I'm still not sure I'd like this feature to be available. Certainly it's not possible to add it after-the-fact due to potential conflicts between members that differed by case.
- twic 12y agoI have a vague theory that the design of most programming languages can be understood as a reaction to the pain their designers experienced in their previous language. So, Java is largely C++ without the things that were painful in C++ (manual memory management, multiple inheritance, operator overloading). Nim's unusual handling of compound names is a reaction to something else that was painful in C++. Hopefully they'll add a Smalltalk/Objective C style format one day.
- FeeTinesAMady 12y agoThat means that all three forms will wind up in any Nim project that gets large enough, though. Hardly a good thing.
- jiggy2011 12y agoIf they all work, does it even make a difference? Besides it would be trivial to write a refactoring tool that can autoreplace all instances with the preferred form.
- yoklov 12y agoWell, it's harder to grep, for one (although far from impossible).
- duaneb 12y agoIt has little benefit and requires new tooling to do simple refactoring like "rename". > Besides it would be trivial to write a refactoring tool that can autoreplace all instances with the preferred form. This should be part of the language if it's being so lax with identifier uniqueness. And if it's so trivial, you should write it so people can't complain anymore.
- deleted 12y ago[deleted]
- dom96 12y agoI don't get why people get so worked up over this. It's not a "little" benefit in my opinion. In regards to drawbacks I can only see one, and that is grepping for the identifiers becomes more difficult.
- duaneb 12y ago> It's not a "little" benefit in my opinion Could you explain it, then? An identifier refers to a single thing. I don't see having multiple ways to refer to that identifier as a win AT ALL—it may be a win for people who are too lazy to learn their own code base, but it makes code hard to read, hard to maintain, and hard to refactor. Meanwhile, having an identifier unique makes it easy to index, easy to manipulate.
- duaneb 12y agoWell thank god a minor inconvenience has been addressed!