Cobra Forums

Posted: **Thu Nov 06, 2008 6:47 pm**

I have fleshed out the Point class with a unit test, contracts, docs, etc. This is a nice example to see how many things are done in Cobra such as customizing equality and hash code, declaring read only properties, etc.

Have a look and feel free to comment and provide feedback.

Posted: **Mon Nov 10, 2008 9:45 am**

Thanks for the example, gotta love how clear and natural Cobra code looks.

This Point class made me wonder, any plans to add operator overloading?

Also, why restrict sets to immutable classes only? I can put objects of any mutable classes in C++ set::set<>, and C++ is supposed to much less user-friendly than Cobra... I'm sure there has to be a reason, I just don't get it.

Regards,
Manuel

Posted: **Mon Nov 10, 2008 1:49 pm**

Yeah, operator overloading is definitely in the plans. Just haven't gotten there yet.

Sets are not immutable. Try this:

class X

    def main is shared
        s = {1, 2, 3}
        assert 2 in s
        assert s.count == 3
        s.add(4)
        assert 4 in s
        assert s.count == 4
        print s

It's the objects that you put in sets (or use a dictionary keys) that need to be immutable. Actually, it just needs to be the case that mutating the objects does not change their .equals and .getHashCode behavior. This is a general computing requirement, not specific to Cobra.

Now for my question: Your user id is jonathandavid, but your name is Manuel. How come? (Just curious.)

-Chuck

Posted: **Tue Nov 11, 2008 3:20 am**

Chuck wrote:Yeah, operator overloading is definitely in the plans. Just haven't gotten there yet.

Sets are not immutable. Try this:
class X

    def main is shared
        s = {1, 2, 3}
        assert 2 in s
        assert s.count == 3
        s.add(4)
        assert 4 in s
        assert s.count == 4
        print s
It's the objects that you put in sets (or use a dictionary keys) that need to be immutable. Actually, it just needs to be the case that mutating the objects does not change their .equals and .getHashCode behavior. This is a general computing requirement, not specific to Cobra.

Now for my question: Your user id is jonathandavid, but your name is Manuel. How come? (Just curious.)

-Chuck

OK, so I can put objects of any class in a set, but I should not modify them once they're there, unless that would not change their .equal & .getHashCode. It's the same in C++ not that I think about it, I just thought that Cobra was actually enforcing this (as in refusing to compile if I tried to create a sef of a mutable class).

As for the operator overloading thing, have you considered trying to make them work as in the Scala programming language? Their approach is really nice, although maybe it wouldn't fit with the structure of Cobra.

Oh, my name is definitely Manuel, I just use the nick jonathandavid sometimes because I think it sounds cool (it does to me, anyway). It's not a name I made up, it's actually a song by british band belle and sebastian. Not the most terribly interesting information, but since you were asking...

Regards,
Manuel

Posted: **Tue Nov 11, 2008 11:37 pm**

The Scala approach is interesting. I found a couple URLs:

http://blogs.tedneward.com/2006/03/05/S ... bject.aspx
http://lampsvn.epfl.ch/trac/scala/ticket/92

I was originally just going to go the C# route, but I'll take this under consideration.

Btw this reminds me that you can already overload all 6 comparison operators in Cobra like so:

class Test

    var _x as int
    
    def init(x as int)
        _x = x
    
    get x from var
        
    def compareTo(t as Test) as int
        return .x - t.x

    def main is shared
        a = Test(1)
        b = Test(2)
        c = Test(1)
        assert a < b
        assert a <= b
        assert b > a
        assert b >= a
        assert a == c

The general form is:

def compareTo(other as MyClass) as int

which Cobra looks for when it sees a comparison operator being used.

-Chuck

Posted: **Wed Nov 12, 2008 1:27 am**

Belle and Sebastian - Jonathan David

Had to listen to it a second time and without the video before I could vibe with it. :-)

Posted: **Wed Dec 17, 2008 10:25 am**

Chuck: two quick questions about your Point sample class.

1) Why not make Point a struct instead of a class?

2) Since you are writing in the doc strings that the class is immutable, why not make it explicit in the code by having x and y be "readonly" fields, C#-style? If the answer is that Cobra does not support readonly fields, then my question is whether it will support them in the future. In case you plan to add them in the future, it might be nice to have a special keyword (immutable?) for them, so that it doesn't become too tied to a particular backend (I think Java uses "final" for the same purpose).

Regards,
Manuel

Posted: **Wed Dec 17, 2008 10:46 am**

(1) The original motivation of the sample was to show a class declaration so I just started with that. In reality, yes you might make Point a struct instead. Interestingly, "cobra -test Point.cobra" works fine right now, but fails if you change "class" to "struct". This is likely just a repeat of the problem you discovered earlier involving contracts, structs and C#'s shallow analysis of code flow.

(2) Sounds fine to me. ticket:100 Patches welcome.

Yay! Our 100th ticket!

Cobra Forums

Point sample

Point sample

Re: Point sample

Re: Point sample

Re: Point sample

Re: Point sample

Re: Point sample

Re: Point sample

Re: Point sample