Page 1 of 1

Ordering of sections in methods

PostPosted: Wed Nov 27, 2013 9:33 pm
by travisby
[by sections, I mean ("test", "require", "ensure", "body")]

I was having a little problem while working on a Poker game implementation in Cobra. I was looking at the example of contracts listed in

"Comparison to Python"

and had noticed the order of the sections in a method there were ["test", "ensure", "body"]

The below code, however did not work for me. I had received this compile-time error.

Code: Select all
$ cobra --test FrenchDeckCard.cobra
FrenchDeckCard.cobra(25,1): error: Missing BODY keyword. Earlier (indented) "test" clauses mandate that the body code also be indented. You need the "body" keyword with indented code following it.
Compilation failed - 1 error, 0 warnings
Not running tests due to errors above.


"""
FrenchDeckCard.cobra

Standard 52-Card playing card
"""


class FrenchDeckCard implements IComparable<of FrenchDeckCard>
"""
One card form a French Deck
"""

var _rank as Rank
var _suit as Suit

cue init(rank as Rank, suit as Suit)
"""
Build our French Card with rank and suit
"""

test
card = FrenchDeckCard(Rank.Four, Suit.Diamond)
assert card._rank == Rank.Four
assert card._suit == Suit.Diamond
ensure
_rank == rank
_suit == suit
body
base.init
_rank = rank
_suit = suit

get rank as Rank
"""
An enum of the Rank of this card. E.X., Two
"""
# TODO
return Rank.Two

get suit as Suit
"""
An enum of the Suit of this card. E.X., Diamond
"""
# TODO
return Suit.Diamond

def compareTo(card as FrenchDeckCard) as int
"""
Compares two FrenchDeckCards to eachother

FrenchDeckCard is ordered soley on Rank, with Ace acting as a high card
"""
# TODO
return 0


enum Rank
"""
Possible Rank of a card. E.X., Two
"""
Two
Three
Four
Five
Six
Seven
Eight
Nine
Ten
Jack
Queen
King
Ace

enum Suit
"""
Possible Suit of a card. E.X., Diamond
"""
Diamond
Heart
Spade
Club



On the other hand, when I changed my code to ["ensure", "test", "body"], my code was able to compile successfully.

"""
FrenchDeckCard.cobra

Standard 52-Card playing card
"""


class FrenchDeckCard implements IComparable<of FrenchDeckCard>
"""
One card form a French Deck
"""

var _rank as Rank
var _suit as Suit

cue init(rank as Rank, suit as Suit)
"""
Build our French Card with rank and suit
"""

ensure
_rank == rank
_suit == suit
test
card = FrenchDeckCard(Rank.Four, Suit.Diamond)
assert card._rank == Rank.Four
assert card._suit == Suit.Diamond
body
base.init
_rank = rank
_suit = suit

get rank as Rank
"""
An enum of the Rank of this card. E.X., Two
"""
# TODO
return Rank.Two

get suit as Suit
"""
An enum of the Suit of this card. E.X., Diamond
"""
# TODO
return Suit.Diamond

def compareTo(card as FrenchDeckCard) as int
"""
Compares two FrenchDeckCards to eachother

FrenchDeckCard is ordered soley on Rank, with Ace acting as a high card
"""
# TODO
return 0


enum Rank
"""
Possible Rank of a card. E.X., Two
"""
Two
Three
Four
Five
Six
Seven
Eight
Nine
Ten
Jack
Queen
King
Ace

enum Suit
"""
Possible Suit of a card. E.X., Diamond
"""
Diamond
Heart
Spade
Club



I know that it is trivial to test and add contracts to my constructor, but it's just for learning purposes. Is this an artifact of just being overly cautious? (i.e., not meant to be used with constructors), or is the documentation out-of-date for the current ordering of these sections?

Re: Ordering of sections in methods

PostPosted: Thu Nov 28, 2013 10:17 am
by Charles
The documentation is incorrect. And it's possible that we allowed more flexibility in the past but then tightened it up.

Also, I hope you don't mind, but I used my powers as admin to slightly edit your message. I changed "fields" to "sections" because in .NET the term "field" is often used for "instance variables" and "member variables". I've been using names like "test section", "body section", etc.

Note that contracts are more general than unit tests because the boolean expressions of the contract apply to every invocation of the method whereas unit tests only cover the cases they are comprised of. Also, unit tests tend to grow over time and be longer than contracts. These observations influenced me to put contracts before unit tests.

And implementation ("body") comes last because by the time you have read the signature, doc string, contracts and unit tests, you may not even need to look at it. It's an implementation detail at that point. :)