Design by contract is a little bit more than placing asserts at the
beginning and end of a method. I would be realy glad if someone points
me to some library wich implements DbC completely in Ruby, eg the fact
that a method can only widen the supermethod's contracts which is
automatically checked.
I assume that "automatically checked" means checking the contracts at
compile time.
That's an undecidible problem.
No he means that a override of a method implemented in a subclass can only widen the contract, and that that is automatically checked. Not that the contract is fulfilled at compile time.
e.g.
class A
def meth(n)
precondition: n > 1
end
end
class B < A
def meth(n)
precondition: n > 0 #Ok, because any inputs that were valid for A#meth are valid for B#meth, this is checked at compile time
end
end
class C < A
def meth(n)
precondition: n > 2 #Will not compile, C#meth accepts a narrower range of inputs than A, does not follow Liskov Substitution Principle
end
end
Note this is not the same thing as checking whether a call will fulfill conditions at compile time, just that the set of values accepted by a subclasses overridden version of a method is a superset of the set of values accepted by the parent's version of the method.
···
On Feb 16, 2006, at 12:35 PM, Edgardo Hames wrote:
On 2/16/06, Jens Auer <jens.auer-news@betaversion.net> wrote:
Thou shalt study thy libraries and strive not to reinvent them without cause,
that thy code may be short and readable and thy days pleasant and productive.
-- Seventh commandment for C programmers
Dňa Sobota 18 Február 2006 21:08 gregarican napísal:
I think I want to create my own scripting language and interpreter that
is perhaps even more obscure. I am going to call it "Izzle." The syntax
will be taken from urban, hop-hop lingo that uses the -izzle suffix
like Pig Latin. E.g. - Rizzle Dizzle Fo Shizzzle. It might be fun for
laughs...
That's true only for preconditions. However, postconditions in
subclasses should strengthen that of parent's, i.e. child's returned
values are a subset of parent's.
Cheers,
Ed
···
On 2/16/06, Logan Capaldo <logancapaldo@gmail.com> wrote:
On Feb 16, 2006, at 12:35 PM, Edgardo Hames wrote:
> On 2/16/06, Jens Auer <jens.auer-news@betaversion.net> wrote:
>>
>> Design by contract is a little bit more than placing asserts at the
>> beginning and end of a method. I would be realy glad if someone
>> points
>> me to some library wich implements DbC completely in Ruby, eg the
>> fact
>> that a method can only widen the supermethod's contracts which is
>> automatically checked.
>
> I assume that "automatically checked" means checking the contracts at
> compile time.
> That's an undecidible problem.
>
No he means that a override of a method implemented in a subclass can
only widen the contract, and that that is automatically checked. Not
that the contract is fulfilled at compile time.
e.g.
class A
def meth(n)
precondition: n > 1
end
end
class B < A
def meth(n)
precondition: n > 0 #Ok, because any inputs that were valid
for A#meth are valid for B#meth, this is checked at compile time
end
end
class C < A
def meth(n)
precondition: n > 2 #Will not compile, C#meth accepts a narrower
range of inputs than A, does not follow Liskov Substitution Principle
end
end
Note this is not the same thing as checking whether a call will
fulfill conditions at compile time, just that the set of values
accepted by a subclasses overridden version of a method is a
superset of the set of values accepted by the parent's version of the
method.
Thou shalt study thy libraries and strive not to reinvent them without cause,
that thy code may be short and readable and thy days pleasant and productive.
-- Seventh commandment for C programmers
class C < A
def meth(n)
precondition: n > 2 #Will not compile, C#meth accepts a narrower
range of inputs than A, does not follow Liskov Substitution Principle
end
end
Actually, in Eiffel, this wouldn't be a compile error. Preconditions in
a derived class is logically ORed with the those in the parent class.
So that the full precondition for C#meth will be
precondition: (n > 2) || (n > 1)
Since the preconditions are ORed, they can only be widened in derivied
classes. If you were using full Eiffel syntax, you would state derived
class preconditions with "require else" rather than the plain "require"
to help you remember that you can only widen the preconditions.
Likewise postconditions in derived classes are ANDed with those in
parent classes, so they can only be narrowed (and "ensure and" is used
rather than the vanilla "ensure" [1]).
···
--
-- Jim Weirich
[1] Ensure in the Eiffel sense (defining preconditions) rather than
ensure in the Ruby sense (finally blocks).
Design by contract is a little bit more than placing asserts at the
beginning and end of a method. I would be realy glad if someone points
me to some library wich implements DbC completely in Ruby, eg the fact
that a method can only widen the supermethod's contracts which is
automatically checked.
I assume that "automatically checked" means checking the contracts at
compile time.
That's an undecidible problem.
Sorry, but I can't see the posting from Edgardo Hames, Feb 16, 2006, at 12:35 PM. Can anybody repost it, so that it shows up in the newsgroup?
···
On Feb 16, 2006, at 12:35 PM, Edgardo Hames wrote:
On 2/16/06, Jens Auer <jens.auer-news@betaversion.net> wrote:
See if I ever try to clarify what someone else said ever again. I get twenty closet Eiffel freaks attacking my pseudo-Ruby
(I'm kidding...)
···
On Feb 16, 2006, at 3:36 PM, Jim Weirich wrote:
Logan Capaldo wrote:
class C < A
def meth(n)
precondition: n > 2 #Will not compile, C#meth accepts a narrower
range of inputs than A, does not follow Liskov Substitution Principle
end
end
Actually, in Eiffel, this wouldn't be a compile error. Preconditions in
a derived class is logically ORed with the those in the parent class.
So that the full precondition for C#meth will be
precondition: (n > 2) || (n > 1)
Since the preconditions are ORed, they can only be widened in derivied
classes. If you were using full Eiffel syntax, you would state derived
class preconditions with "require else" rather than the plain "require"
to help you remember that you can only widen the preconditions.
Likewise postconditions in derived classes are ANDed with those in
parent classes, so they can only be narrowed (and "ensure and" is used
rather than the vanilla "ensure" [1]).
--
-- Jim Weirich
[1] Ensure in the Eiffel sense (defining preconditions) rather than
ensure in the Ruby sense (finally blocks).
