Syntax relaxation on var

[Charles]

Based on feedback, I've relaxed the syntactic restriction that vars start with an underscore (_). This means you can now say:

class Point

    var x as int
    var y as int

    get isPositive as bool
        return .x > 0 and .y > 0

class Program

    def main is shared
        p = Point()
        p.x = 1
        assert p.y == 0

Note that because the vars are members of the object, you still have to refer to them with a dot. Python programmers will recognize this as a shorter form of "self.x". C# programmers may take some getting use to this. The point (hehe) is to put members in a different "namespace" as local variables. It can make code easier to read, avoid name clashes and should work nicely with Intellisense.

If you forget the leading dot, the compiler will now note that there is a member with the same name in the error message:

Code: Select all

Unknown identifier: "x". There is a member named "x" with a similar name that you can access with a leading period (".").

Now suppose at some point that you realize you need some code wrapped around that access. You can rename the var and wrap it in a property like so:

Code: Select all

    var _x as int

    get x as int
        print 'Accessing x'
        return _x

In all the places you wrote ".x" the property will now be accessed with no additional edits required on your part.

There are some disadvantages to vars over properties. Some of the .NET library classes are property-centric including PropertyGrid and DataGridView, which will not look at vars but will look at properties. Also, if you're vending out a library, you'll want to stick with protected or private vars wrapped by public properties.

As usual, you can get the latest code at http://cobra-language.com/source/

[Charles]

Also, recall that underscored members ("_foo") are protected by default while non-underscored members ("foo") are public. You can override this by tacking on "is protected" or "is private", for example.

[necromanco]

Hello,

I am very glad for the existence of Cobra. It is almost exactly my dream language!

As the prefix system for properties and variables is much elegant and enforces patterning,
I wonder if instead of relax the rule for the initial underscore, it would be possible to
make implicit class variable.

For example:

Code: Select all

class MyClass

    # var _myNumber = 6 # present system
    # pro myNumber from var # present system

    pro myNumber = 6 # new system; there is no need to declare var _myNumber



By the way, I am giving up using IronPython for Cobra, right now.
Thanks for this nice job

-necromanco

[Charles]

Thanks!

I didn't mean to imply with this relaxation that I was no longer interested in a tighter syntax to replace:

var _foo as String
get foo from var

Btw what do you suggest for the case where there is no initial value to assign?

var _customer as Customer?
get customer from var

I have something in mind, but want to hear ideas first.

Regarding the non-underscored variables, my main motivation was performance for people working on mathematical or scientific code. Neither Cobra nor .NET offer property/method inlining right now. And I was encouraged by the fact that you can wrap the var in a property later and all the access points remain the same with no required edits.

[necromanco]

Hello,

I had understood already how your solution works and i believe that it is nice .
Here is what came to my mind at your question:

Code: Select all

class Proposal

   get customer as Customer?
   # The line above explicitly declares a read only property of type 'Customer?'
   # and implicitly declares the variable '_customer' of type 'Customer?'.
   
   def init
      _customer = 'some customer'
      print .customer



Thanks!

-necromanco

[Charles]

Interesting. So simply skipping the body means that the property is implicit.

I was thinking that since the "get customer from var" syntax would still work, and since "var _foo as Foo" will always work, it would be a combo:

class Proposal

    get customer from var as Customer?
    # the combo of a property and var decl

I agree that the _foo var would be available.

Another thought. C# supports having different visibility on the getter vs. the setter. The most common case is a public getter and protected setter. Cobra most certainly will at some point too. So:

class Proposal

    pro customer from var as Customer?
        get is public
        set is protected

I like your idea too, so I will have to mull it over. Further comments from you and others are welcome.

[necromanco]

Well, while the shortest syntax is visually cleaner, the combo declaration is nice as well and seems more coherent with the other declarations than the
shortest syntax. Beyond this, the combo declaration is ready for:

Code: Select all

class Proposal

   get customer from _varWithNoMatchingName as Customer?


As long as a name starting with underscore means non public and a simple property(and its variable) can be declared in one line, I will be fine with any decision.

About different visibilities for getter and setter I can't think anything better than your
solution.

[Charles]

Completed ticket:46 in changeset:1720.

[natter]

thx for this change. the leading "_" rule was one of the few things i absolutly didnt like.

i wouldnt dare to ask, if it wasnt cobra ..
can you relax it even one step further to allow:

Code: Select all

class Point
    get isPositive as bool
        return .x > 0 and .y > 0

class Program
    def main is shared
        p = Point()
        p.x = 1
        assert p.y == 0


[Charles]

In your example, if someone says:

p = Point()
print p.isPositive

Where would the .x and .y come from?

Cobra uses the same class/object model as C# and VB (which is nearly the same as Java) and will continue to do so. This has benefits over the Python approach including greater performance, less memory consumption and two-way compatibility with .NET (meaning you vend your classes out to C# and VB programmers to use). Yes, it has the disadvantage of less flexibility--you cannot make new properties on the fly.

Eventually Cobra will have dynamic binding hooks a la Smalltalk and Python so that you could implement dynamic properties, but this is not high on my list of priorities right now.