[ruby-talk:03583] Re: Static Typing( Was: Waffling between Python and Ruby)

"Frank Mitchell" <[e-mail]> writes:

> Dave Thomas wrote in message ...
> >"Frank Mitchell" <[e-mail]> writes:
> >> (I also believe not specifying the *contract* of each involved
> >> object's methods is a mistake.  On a large-ish Objective-C system I
> >> worked on we had a few bugs caused by passing the wrong object that
> >> just happened to implement the right method in the wrong way.
> >> E.g. "price" as a message to return an attribute vs. "price" as a
> >> command to initiate an involved calculation with numerous side
> >> effects which fails because the object isn't in a consistent state.)
> 
> Maybe I was misunderstanding the original poster, but he seemed to be
> advocating DbC without any notion of types other than "object that responds
> to message X".  To state the obvious, if the language has a notion of
> interface, protocol, or type, it's merely necessary to check that the object
> conforms to that type, at compile-time or run-time, since the contract is
> available in the interface/protocol/type definition.

Not always (there are issues with polymorphism) but in general.

> In the every-message-for-itself case, it would seem to me that you *would*
> have to check each argument to make sure it implements all messages your
> method expects, and that those messages conform to some required contracts
> ... otherwise you're open to the problem I mention above.

...

> I bow to your Pragmatism,

a respectful touching of the forelock is sufficient ;-)

> but DbC is supposed to detect design and code mismatches, and the
> biggest mismatch I can think of is objects that don't implement
> messages, or implement the name but not the expected external
> behavior.  If a language pretends to support DbC but doesn't support
> that sort of error, it isn't true DbC.

I guess you're a better programmer than me. The errors I see are
typically failures of implementation, rather than passing around the
wrong objects. In fact, if you discount the occasional nil pointer
passed in when I was expecting a real object, I can honestly say I
can't remember the last time I passed in the wrong kind of object to a
routine.

But I come back to my original point. For me at least, the biggest
benefit of DbC is thinking about using it. It helps me organize the
classes, clarifies my interfaces, and reduces coupling, all without a
single runtime assertion.

But, I'm not an expert on the subject, so I'll probably let it stop
there.

Thanks for the discussion.


Dave