Cobra Forums

I see that the names of Cobra methods are required to be lower case. At least this is what the compiler seems to be telling me. This is contradictory to the usual .NET conventions (at least as far as I understand them). It also means that when I call methods in the standard .NET libraries I have to use different names for those methods than what is documented. I assume there is some compelling reason for this inconsistency, and I'm wondering what that reason might be. I looked around a little on the Cobra language web site, but I didn't find anything that addresses this.

I guess it has to do with Chuck wanting to follow Python's conventions (this language is not called Cobra for no reason, after all). I personally like lower case method names (I'd rather have this_kind_of_names to camelCase though, but that's a different story), but I understand than having a convention that's so different from that of the underlying platform can be an important source of confusion. I've had no problem with this convention myself so far, thought. And you always have the -correct-case option, which should be quite useful for people making the transition to Cobra.

Ah, but it's not just Python. Here's a partial list of languages that start methods with lowercase letters:

C++
Java
Python
Ruby
Objective-C
Smalltalk
PHP?

That represents a lot of programmers and a lot of code!

Also, it's only currently the case that Cobra does not match the VM. Once Cobra is running on JVM as well, it will match one and not the other. Once Cobra has an Objective-C backend, it will match 2 out of 3.

Btw Cobra capitalizes your method names under the hood so that C# and VB.NET folks will see your .dll as being "normal".

Languages like C++ and Java don't actually require lower case method names. That's just a convention. In languages where lower case is required for certain things (for example OCaml, Prolog, etc), it's usually because uppercase letters are reserved for something semantically different. However, it sounds like that's not the situation for Cobra. Here the language is "just" imposing a particular naming convention on programmers. That's not necessarily a bad thing, but it does seem odd to impose a convention that contradicts that recommended by the underlying platform.

I appreciate that languages designed without .NET in mind might want to use conventions that existed for that language before .NET came along. I can also appreciate that a specific programmer or team of programmers might want to use a convention that is different than Microsoft's recommendation for whatever reason. But is it really desirable to force all programmers to use a particular (non-standard) convention just for the sake of doing so? Is it really desirable to change the names used by external third party libraries?

I'm also playing around with AdaCore's GNAT for .NET. The naming convention that is traditional in Ada is slightly different than the .NET "standard" as well. However, when interacting with the .NET core libraries, the regular .NET names are used. The GNAT compiler does not attempt to translate names for the sake of hiding a mismatch in naming conventions. Honestly, that seems less confusing to me.

Sure it's a convention in C++ and Java, but it's exhibited by *thousands* of source files. If you joined a Java developer shop and started declaring capitalized methods they would immediately correct you, just like if you didn't indent your code blocks. And if you put out an open source Java lib with capped methods, people would roll their eyes and refuse to use it until you "corrected it".

Regarding Cobra, I do think it's desirable to enforce a consistent coding convention. Other enforcements include capitalizing classes, lower casing args and locals and accessing members through dot ("foo.bar") or implicitly if there is an underscore prefix ("_bar"). These enforcements provide consistency between developers, projects and open source libraries. I don't plan on relaxing them.

If it helps any, I do plan on implementing case correction for members at some point. (Or would accept a patch.)

Chuck wrote:Sure it's a convention in C++ and Java, but it's exhibited by *thousands* of source files. If you joined a Java developer shop and started declaring capitalized methods they would immediately correct you, just like if you didn't indent your code blocks.

But won't the .NET community at large feel the same way when they see Console.WriteLine spelled Console.writeLine?

Actually since making my last post I've been reading the "Design Guidelines for Developing Class Libraries" document here:

http://msdn.microsoft.com/en-us/library/ms229042.aspx

As usual the issues are more complicated than they at first appear. I see that the .NET Framework is intended to support both case sensitive and case insensitive languages. Thus one is not supposed to create public names that differ only in case even if one's language would allow it. This issue actually comes up for Ada since that language is, in fact, case insensitive. Thus in an Ada program it must be possible to make a call such as Console.writeline("Hello") since the casing of "writeline" is not allowed to be significant. On the other hand, the industry wide naming convention in the Ada community uses underscores to separate words. Thus Console.Write_Line("Hello") has a more "Ada-like" look. Nevertheless GNAT for .NET does not attempt to convert Write_Line to WriteLine for the sake of making such a call possible. When invoking .NET libraries, .NET names are used (not considering differences in case, as per language requirements).

Cobra is case sensitive so my expectation was that I would have to spell the .NET names *exactly* as they are documented. It was a surprise to find out that doing so causes an error!

Chuck wrote:Regarding Cobra, I do think it's desirable to enforce a consistent coding convention.

I'm all for consistent coding conventions. I even support compiler enforced consistency (in looser languages I've used style checking tools for exactly this purpose). I don't think requiring lower case method names (for the initial letter) in Cobra is a horrible thing, and I can certainly live with it. However, I do think that for the sake of enforcing a particular (somewhat arbitrary) convention inside the Cobra language you've introduced a quirky inconsistency with the rest of the .NET universe.

Chuck wrote:If it helps any, I do plan on implementing case correction for members at some point. (Or would accept a patch.)

What do you mean by "case correction?" Does that mean the language would treat members in a generally case insensitive manner? That could be cool. That would be easy to understand and play well with the .NET philosophy. Would that mean it would be an error to create two members with names differing only in case? I like that idea.

pchapin wrote:

Chuck wrote:Sure it's a convention in C++ and Java, but it's exhibited by *thousands* of source files. If you joined a Java developer shop and started declaring capitalized methods they would immediately correct you, just like if you didn't indent your code blocks.

But won't the .NET community at large feel the same way when they see Console.WriteLine spelled Console.writeLine?

Some will and we occasionally get that reaction. Most seem okay with it.

pchapin wrote:Actually since making my last post I've been reading the "Design Guidelines for Developing Class Libraries" document here:
http://msdn.microsoft.com/en-us/library/ms229042.aspx
...
Cobra is case sensitive so my expectation was that I would have to spell the .NET names *exactly* as they are documented. It was a surprise to find out that doing so causes an error!

Yes, it's a growing pain. There will probably be some others depending on your background, your exposure to Python, etc. Hopefully the error message gave you the correct method name to use.

pchapin wrote:

Chuck wrote:Regarding Cobra, I do think it's desirable to enforce a consistent coding convention.

I'm all for consistent coding conventions. I even support compiler enforced consistency (in looser languages I've used style checking tools for exactly this purpose). I don't think requiring lower case method names (for the initial letter) in Cobra is a horrible thing, and I can certainly live with it. However, I do think that for the sake of enforcing a particular (somewhat arbitrary) convention inside the Cobra language you've introduced a quirky inconsistency with the rest of the .NET universe.

True, but I see it as less arbitrary and quirky than you do.

pchapin wrote:

Chuck wrote:If it helps any, I do plan on implementing case correction for members at some point. (Or would accept a patch.)

What do you mean by "case correction?" Does that mean the language would treat members in a generally case insensitive manner? That could be cool. That would be easy to understand and play well with the .NET philosophy. Would that mean it would be an error to create two members with names differing only in case? I like that idea.

It's already an error to create two members with names differing only in case.

The "case correction" is a command-line option: cobra -correct-case:yes. When turned on, Cobra will see "list<of int>" and change it to "List<of int>" with no error or halting of compilation. Right now it only works on types. If your editor can be configured to automatically reload files with no prompt, it can be quite convenient. It does not work of members like "tw.WriteLIne" --> "tw.writeLine" but will some day.

Also, I will likely change the option to -correct-source:case and then in the future we can add additional options like reserved-words, transposed-names, etc. plus "all". Of course, the key is to avoid any correction that is ambiguous.

OTOH if you are of the opinion that Microsofts specification of leading caps method names for .Net libraries is an example of another brain damaged gratuitous difference from everyone else (and historical convention) just for the sake of it, cobras handling is a reassertion of normality.

Chuck wrote:The "case correction" is a command-line option: cobra -correct-case:yes. When turned on, Cobra will see "list<of int>" and change it to "List<of int>" with no error or halting of compilation. Right now it only works on types. If your editor can be configured to automatically reload files with no prompt, it can be quite convenient. It does not work of members like "tw.WriteLIne" --> "tw.writeLine" but will some day.

Okay, I understand what you're saying. Personally I don't think I'd want to use that feature because I'm not 100% comfortable with the idea of the compiler rewriting my source files. Perhaps I could get used to it. In any case, it means that the spelling of things is ultimately not consistent (with .NET) so I might as well just write the names the Cobra way in the first place.

I could see the feature as being handy for processing programs automatically converted from some other .NET language.

Anyway, thanks for your thoughts on all of this.

BTW, the error messages produced by the Cobra compiler are very clear and detailed. I did not have any problems figuring what I needed to do based on them. Thanks for that!

pchapin wrote:

Chuck wrote:The "case correction" is a command-line option: cobra -correct-case:yes. When turned on, Cobra will see "list<of int>" and change it to "List<of int>" with no error or halting of compilation. Right now it only works on types. If your editor can be configured to automatically reload files with no prompt, it can be quite convenient. It does not work of members like "tw.WriteLIne" --> "tw.writeLine" but will some day.

Okay, I understand what you're saying. Personally I don't think I'd want to use that feature because I'm not 100% comfortable with the idea of the compiler rewriting my source files. Perhaps I could get used to it. In any case, it means that the spelling of things is ultimately not consistent (with .NET) so I might as well just write the names the Cobra way in the first place.

Yeah, I understand some people will not be comfortable with that. Personally, I'm looking forward to expanding it, turning it on via an environment variable and never hitting SHIFT again.

pchapin wrote:I could see the feature as being handy for processing programs automatically converted from some other .NET language.

Anyway, thanks for your thoughts on all of this.

You're welcome.

pchapin wrote:BTW, the error messages produced by the Cobra compiler are very clear and detailed. I did not have any problems figuring what I needed to do based on them. Thanks for that!

Yes, I think that feature is very important for speeding up learning and making Cobra more popular. If you find an error message that can be improved, do not be shy about suggesting so on the forums with some example code to produce the error.