Cobra Forums

Hi!

In Python:

Code: Select all

>>> type(None)
<type 'NoneType'>


In Ruby:

Code: Select all

>> nil.type
=> NilClass


In Cobra:

Code: Select all

print nil.getType # error: DOT operator applied to operand of type "<nil>".


Code: Select all

x = not nil
print x # output: true
print x.getType # output: System.Boolean

y = nil
print y # output: nil
print y.getType # error: An unhandled exception has occurred.

z as int?
print z.getType # error: System.NullReferenceException


Is 'nil' working like it should be?

Thanks.
-necromanco

Yes, nil is working like it should be.

In Cobra, nil is like the "null" in C# and Java and "Nothing" in Visual Basic. It's a special value not associated with any class. It's also a lot like NULL in C which is often (always?) defined as "(void*)0".

As you pointed out, in Python and Smalltalk (and hence Ruby), it's an object like any other, except there is a special literal for it.

Which design is best is open to debate. But in the context of maintaining extreme two way compatibility with C# (and even Java) I went with the C# approach.

Note that "x.getType" gave System.Boolean because the expression "not foo" always results in a boolean value, true or false.

Also, you might enjoy experimenting with "ct_trace" if you want to see the inferred type of a variable:
"ct_trace" takes place at compile-time and only once. It has no effect on your resulting program. The output is ugly but useful when working on the compiler.

In C#:

Code: Select all

using System;

public class RunTimeCrash
{
   public static void Main()
   {
      int? x = 3;   
      Console.WriteLine(x.GetType());
      var y = Console.ReadLine();
      if (y == "Break at run-time, please!"){x = null;}
      Console.WriteLine(x.GetType());
   }
}

Well, one thing that I am used to hear in favor of compiled languages is that they point errors at compile time, instead of run time. In this case, C# produces an error at run time that less safe interpreted languages would not produce.

I wonder if the extreme two way compatibility with C# is more a convenience for the present implementation or a decision on pure design of the language.

Thanks.
-necromanco

You have a good point. Although misspelled variable and method names are more common errors that are found by static language compilers. Also, there aren't too many of these cases in Python and Ruby. Most "x.foo()" in Python where x is None will produce an AttributeError at run-time.

Regarding extreme two way compatibility with C#, two of the motivations aren't listed in your speculation. One is the ability to write libraries in Cobra that can be naturally consumed by C# and VB developers. Another is performance: To the extent that a language "goes with the flow" in .NET, you are likely to get full C#esque performance.

Also, it's notable that Java and Objective-C are in the same neighborhood as C# regarding many language design points. I expect Cobra will run on those platforms at some point in the future.