In article <8ir5bg$5cklh$1 / fu-berlin.de>, "Joachim Durchholz" 
<joachim.durchholz / halstenbach.com.or.de> wrote:

> However, Design by Contract isn't just assertions. What makes DbC stand
> out is that contract rules are inherited to subclasses.

Yes. But this can be inherited in a dynamically typed language
that might support DbC, too.

Dynamically typed doesn't mean that you can't declare
and use types or classes. It just means that a compiler
might not try to infer type declarations
and/or enforce type declarations at compile time.
At runtime types and classes may be available.

> This is a very
> unspectacular property in a dynamically-typed language, but in a
> statically-typed language, it means that I can write code like
>   x: FOO
>   x.some_feature
> and I can look up the contract of 'some_feature' in FOO and be sure that
> at least the contract that I find there will be honored, no matter what
> kind of object was assigned to x.

The same is true for dynamically typed languages with DbC.

> In a dynamically-typed language, I don't know that x will always be of
> type FOO,

Just assert it. This can be done in many ways.

> so there's no place to look what the contract of
> 'some_feature' is.

You have to lookup the contract at runtime anyway. Since
in dynamically typed languages the classes are a property
of the objects (at any time you can ask what type or
class the object is of) you just look that up too.

-- 
Rainer Joswig, BU Partner,
ISION Internet AG, Steinht 9, 20459 Hamburg, Germany
Tel: +49 40 3070 2950, Fax: +49 40 3070 2999
Email: mailto:rainer.joswig / ision.net WWW: http://www.ision.net/