Forums

A couple of (ok 4) miscellaneous questions.

General discussion about Cobra. Releases and general news will also be posted here.
Feel free to ask questions or just say "Hello".

A couple of (ok 4) miscellaneous questions.

Postby AlGonzalez » Mon Feb 11, 2008 4:05 pm

1. Why force function/property names to be lowercase?
IMO, this makes it more difficult to use existing .NET libraries. For example, if I look up information on the generic List<T>, I find that is has a property named Count, but in the Cobra Programming Language, I need to remember to lower case it.

Also, not sure how you are implementing the translation, but what happens if I try to use a 3rd party class that has a method that is actually lowercase - are you uppercasing these when you create the C# code. If so, this case would fail. I just ran a quick test and can confirm that this does in fact fail. You run into these case in libraries that have been ported from the Java world.

2. Another case related question deals with Type declarations. Why can I write "var i as int #note lowercase i" but i have to write "var s as String #note uppercase S"?
I know that in another post you state that 'Object' and 'String' are the actual class names so there isn't an 'object' and 'string' like in C# - but continuing that logic, the actual framework types for integers are System.Byte, System.SByte, System.UInt16, System.Int16, System.UInt32, System.Int32, System.UInt64, System.Int64 and for floating point they are System.Single, System.Double, System.Decimal. I won't list them all, but int is a c# alias for System.Int32 and decimal is an alias for System.Decimal and finally string is an alieas for System.String.

3. Can doc strings be accessed in code like Python's __doc__ or are they just a standardized placeholders to document the code?

4. Does the Cobra Programming Language have a line continuation character like Python's backslash?
AlGonzalez
 
Posts: 13
Location: Greenville, SC - USA

Re: A couple of (ok 4) miscellaneous questions.

Postby AlGonzalez » Mon Feb 11, 2008 4:39 pm

Another issue with the forced convention of function/property names being camelCasing is that if you write an assembly in Cobra and distribute to others, it will clash with the more common (in the .NET world anyway) PascalCasing for public methods.
AlGonzalez
 
Posts: 13
Location: Greenville, SC - USA

Re: A couple of (ok 4) miscellaneous questions.

Postby neuruss » Mon Feb 11, 2008 6:32 pm

I was about to ask exactly the same questions :-)
I'd like to know if there is really a compelling reason to not follow the standard naming conventions.
Note that, being a .NET language and not having extensive documentation to learn from, these oddities make the learning curve steeper than needed.

The good thing about learning other open source .net languages (Boo for example) is that if you don't know how something works, you just learn the c# way and that's it. You just have the beautiful and easy pythonic syntax but all the other things related to .NET remain standard.

Another thing that I found unpractical and verbose is the need to define a property in order to make a variable public.
It takes two lines in Cobra what it takes just one line and an extra word in others (unless I'm wrong and Cobra does have a better way to do it).

neuruss
neuruss
 
Posts: 23

Re: A couple of (ok 4) miscellaneous questions.

Postby khjklujn » Mon Feb 11, 2008 9:20 pm

I first bumped into this issue when trying to make use of wx.NET where all of the method names are PascalCase, but I figured wx might be kind of a corner case in the .NET world, and I could live without it if I had to.

However, I'm now running into a problem that might be a little more fundamental. I'm trying to create an object that will have a custom sort ability. In Python it would be something like:
Code: Select all
class MyObject:
   def __init__(self, name, value):
      self.name = name
      self.value = value
   
   def __cmp__(self, other):
      return self.value.__cmp__(other.value)
   
   def __repr__(self):
      return "MyObject(%s, %d)" % (self.name, self.value)

if __name__ == "__main__":
   t = []
   t.append(MyObject("bob", 5))
   t.append(MyObject("julie", 2))
   t.sort()
   for i in t:
      print i

The results should be:
MyObject("julie", 2)
MyObject("bob", 5)

I would expect the Cobra equivalent to be something like:
class MyObject
implements IComparable

var _name as String
var _value as int

pro name from var
pro value from var

def init(name as String, value as int)
.name = name
.value = value

def compareTo(other as MyObject) as int
return .value.compareTo(other.value)

def asString as String
return "MyObject([.name], [.value])"

class Program
def main is shared
t = List<of MyObject>()
t.add(MyObject("bob", 5))
t.add(MyObject("julie", 2))
t.sort
for i in t
print i.asString

Without the "implements", the sort fails at run time because MyObject isn't implementing the right interface, but with the "implements", it fails at compile time because I haven't defined a "CompareTo" method.
khjklujn
 
Posts: 29

Re: A couple of (ok 4) miscellaneous questions.

Postby AlGonzalez » Mon Feb 11, 2008 9:44 pm

The problem in this case is with the IComparable implementation signature.

Add this method and see what you get:
def compareTo(other as Object) as int
return .value.compareTo((other to MyObject).value)
Note: the parameter is type Object and i'm casting it to MyObject in the code.
In C# you'd get the error that 'MyObject' does not implement interface member 'System.IComparable.CompareTo(object)'
AlGonzalez
 
Posts: 13
Location: Greenville, SC - USA

Re: A couple of (ok 4) miscellaneous questions.

Postby Charles » Mon Feb 11, 2008 11:44 pm

AlGonzalez wrote:1. Why force function/property names to be lowercase?
IMO, this makes it more difficult to use existing .NET libraries. For example, if I look up information on the generic List<T>, I find that is has a property named Count, but in the Cobra Programming Language, I need to remember to lower case it.

That's trivial compared to other C# translation issues like removing curly brackets from the library examples. Also, it's unlikely that after writing any fair amount of Cobra code you would forget to lower case the methods. I use the MSDN docs all the time.
AlGonzalez wrote:Also, not sure how you are implementing the translation, but what happens if I try to use a 3rd party class that has a method that is actually lowercase - are you uppercasing these when you create the C# code. If so, this case would fail. I just ran a quick test and can confirm that this does in fact fail. You run into these case in libraries that have been ported from the Java world.

Cobra takes multiple measures to make its DLLs palatable to C# users: It embeds the Cobra runtime so no Cobra.Lang.dll is needed. It capitalizes members. It favors .NET collections ([1, 2] is a generic .NET List<of int> not a "CobraList" or something).

But you're worried about consumption when the Google guys push out Java-style C# which we've seen them do. I can teach Cobra to handle this case. Thanks for bringing it up.

AlGonzalez wrote:2. Another case related question deals with Type declarations. Why can I write "var i as int #note lowercase i" but i have to write "var s as String #note uppercase S"?
I know that in another post you state that 'Object' and 'String' are the actual class names so there isn't an 'object' and 'string' like in C# - but continuing that logic, the actual framework types for integers are System.Byte, System.SByte, System.UInt16, System.Int16, System.UInt32, System.Int32, System.UInt64, System.Int64 and for floating point they are System.Single, System.Double, System.Decimal. I won't list them all, but int is a c# alias for System.Int32 and decimal is an alias for System.Decimal and finally string is an alieas for System.String.

Okay, you have a point with the aliases, but then why doesn't C# let us say "list<of int>" and "new button()"? In Cobra, there are primitive types like bool, char, int, etc. Yes, these are backed by the uppercased structs. Then there are classes, all of which are named by their real library name. "String" is "String" just like "List" and "Dictionary".

AlGonzalez wrote:3. Can doc strings be accessed in code like Python's __doc__ or are they just a standardized placeholders to document the code?

Just placeholders but I guess it would be pretty easy to turn them into .NET attributes and make them accessible at run-time.

AlGonzalez wrote:4. Does the Cobra Programming Language have a line continuation character like Python's backslash?

No, but it certainly needs one. I'll see if I can get that in for the next release. You don't need one for list and dictionary literals which can go multiline just like in Python. Unlike Python, I don't have that for method calls yet.

-Chuck
Charles
 
Posts: 2510
Location: Los Angeles, CA

Re: A couple of (ok 4) miscellaneous questions.

Postby Charles » Tue Feb 12, 2008 12:05 am

neuruss wrote:I was about to ask exactly the same questions :-)
I'd like to know if there is really a compelling reason to not follow the standard naming conventions.
Note that, being a .NET language and not having extensive documentation to learn from, these oddities make the learning curve steeper than needed.

The good thing about learning other open source .net languages (Boo for example) is that if you don't know how something works, you just learn the c# way and that's it. You just have the beautiful and easy pythonic syntax but all the other things related to .NET remain standard.

I can't buy the idea that other parts of the syntax are more radically different, but it's the casing that is the biggest issue. Also, I do what you've described with Cobra. For example, "How to do threads in Cobra?" A: Search for "C# threads example" and translate. The camelCase was the least difficult part of the translation!

neuruss wrote:Another thing that I found unpractical and verbose is the need to define a property in order to make a variable public.
It takes two lines in Cobra what it takes just one line and an extra word in others (unless I'm wrong and Cobra does have a better way to do it).

By breaking out the property, it's possible to hang a doc string off of it. I believe the weakness I saw in Boo's attribute approach is that your doc string would go with the variable. Also, I like that idea that at any time you can make the short cut property "get name from var" into a full property by chopping "from var" and continuing to code like you normally would.

However, I admit that I've been musing on a way to get rid of the "double declaration" as it does come up frequently. So here is a proposal:
# current way and will still be supported:

class Person

var _name as String

def init(name as String)
_name = name

get name from var

# proposal:

class Person

def init(name as String)
_name = name

get name as String from var
"""
Returns the name of the person.
"""


Note that the "get name as String" part is exactly what you normally type for a property. For example, you would have to say "get foo as Bar" for any kind of "calculated" property such as "get area as decimal" for a Shape. But then in place of providing an implementation, you can say "from var". Note that "var" is the same keyword used to declare variables.

The proposal accomplishes avoiding the extra line and putting the doc string with the property where it belongs.

Reactions?

-Chuck
Charles
 
Posts: 2510
Location: Los Angeles, CA

Re: A couple of (ok 4) miscellaneous questions.

Postby AlGonzalez » Tue Feb 12, 2008 7:52 am

Chuck wrote:I can't buy the idea that other parts of the syntax are more radically different, but it's the casing that is the biggest issue. Also, I do what you've described with Cobra. For example, "How to do threads in Cobra?" A: Search for "C# threads example" and translate. The camelCase was the least difficult part of the translation!


First, just let me say that I think a lot of the ideas behind Cobra are fantastic. As to the casing, you'd be suprised. Most of us are used to learning different syntax/keywords when looking at a new language, but many are not a fan of the restrictions the language places on the part that you are creating which is the type and method names.

Peoples preferences are often based on the minor issues. Just look at how many people do or don't like Python just based on the indentation blocks or how many people prefer either C# or VB only on the fact that one is case-sensitive and the other isn't

Personally, I'm fairly adaptable, I use both C# and VB. My concern is the small bugs that can creep in when the compiler is having to do workarounds instead of just passing a method call to the library as I wrote it. I also don't like the idea that if I write a library of routines and package it up with a help file, users of other .NET languages will have to be told to uppercase the property/method calls instead of using them like they see in the examples.

That will be my last complaint on the case issue unless I run into something that doesn't work like calling of the camelCased methods in a .NET library.

Again, thanks for a very nice and thought provoking new dev language.
AlGonzalez
 
Posts: 13
Location: Greenville, SC - USA


Return to Discussion

Who is online

Users browsing this forum: No registered users and 4 guests

cron