Forums

Point sample

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

Point sample

Postby Charles » 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.
Attachments
Point.cobra
(2.13 KiB) Downloaded 145 times
Charles
 
Posts: 2510
Location: Los Angeles, CA

Re: Point sample

Postby jonathandavid » 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
jonathandavid
 
Posts: 159

Re: Point sample

Postby Charles » 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
Charles
 
Posts: 2510
Location: Los Angeles, CA

Re: Point sample

Postby jonathandavid » 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
jonathandavid
 
Posts: 159

Re: Point sample

Postby Charles » 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
Charles
 
Posts: 2510
Location: Los Angeles, CA

Re: Point sample

Postby Charles » 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. :-)
Charles
 
Posts: 2510
Location: Los Angeles, CA

Re: Point sample

Postby jonathandavid » 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
jonathandavid
 
Posts: 159

Re: Point sample

Postby Charles » 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! :D
Charles
 
Posts: 2510
Location: Los Angeles, CA


Return to Discussion

Who is online

Users browsing this forum: No registered users and 6 guests

cron