Asp Forum - Re: OT: Is this worth a try?

John Carter

2/15/2006 10:20:00 PM

7 Answers

Jens Auer

2/16/2006 2:30:00 PM

John Carter wrote:
> On Thu, 16 Feb 2006, David Vallner wrote:
>
>> b) The prime example of a bondage and discipline language. Which you
>> might or
>> might not like, but If you do, you're probably better off with C++ for
>> overall usefulness.
>
>
> Note that B&D is all bad, but you certainly can mimic many of the B&D
> features of Eifel in Ruby.
>
> In fact I personally recommend doing both Test Driven Development to
> drive the code through it's paces, but putting the assert's as
> preconditions, postconditions and invariants within the code in the
> Eifel style.
>
> You find run time bugs much faster that way.
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.

Eivind Eklund

2/16/2006 6:21:00 PM

On 2/16/06, Edgardo Hames <ehames@gmail.com> 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.

Yup, so that's not what Eiffel compilers do. Instead, they administer
the execution of run time checks. Eiffel use trickery to ensure that
you only program cases that ARE decideable, too: Loop invariants are
checked by having a block that has to return asmaller value for each
iteration of the loop. Fortunately, many many invariants *can* be
specified in a useful way, even if there are some cases that can't.

Also, technically, isn't that only undecidable if you assume an
infinite size Turing machine, while a finite size computer IS
decidable, it's just impractical? At least as long as you actually
can formally specify the invariant?

Eivind.

Logan Capaldo

2/16/2006 7:30:00 PM

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.

> Cheers,
> Ed
> --
> Encontrá a "Tu psicópata favorito" http://tuxmaniac.bl...
>
> 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
>

Edgardo Hames

2/16/2006 7:57:00 PM

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.

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
--
Encontrá a "Tu psicópata favorito" http://tuxmaniac.bl...

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

Jim Weirich

2/16/2006 8:36:00 PM

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).

--
Posted via http://www.ruby-....

Logan Capaldo

2/16/2006 10:48:00 PM

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).
>
> --
> Posted via http://www.ruby-....
>

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...)

Jens Auer

2/17/2006 8:41:00 AM

Logan Capaldo 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.
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?

comp.lang.ruby

Re: OT: Is this worth a try?

John Carter

Jens Auer

Eivind Eklund

Logan Capaldo

Edgardo Hames

Jim Weirich

Logan Capaldo

Jens Auer

x Login to ForumsZone