Several months ago, I made a posting regarding a possible enhancement to
Ruby to facilitate Design by Contract (DbC). Matz and Justin were kind
enough to reply w/their thoughts and I was curious to know whether there is
any hope for such functionality in any near future release of Ruby.
Regards,
Ken.
“Ken Hilton” kenosis@attbi.com schrieb im Newsbeitrag
news:xbUpa.606467$L1.172152@sccrnsc02…
Several months ago, I made a posting regarding a possible enhancement to
Ruby to facilitate Design by Contract (DbC). Matz and Justin were kind
enough to reply w/their thoughts and I was curious to know whether there
is
any hope for such functionality in any near future release of Ruby.
Since ruby is dynamically typed currently I don’t see much chance to have
DBC in ruby. You can’t even fix argument types of methods in the
interface. You can of course do argument (type) checking at runtime, but
there’s not static type information about arguments.
see here as well: http://www.rubygarden.org/ruby?DesignByContract
robert
On a somewhat related note I wanna mention my thesis which
describes a system which uses contracts (or rather executable
behavioral specifications which is what I tend to call them) as an
integral part of a SW dev environment.
Thesis title is
Biomimetic Software Engineering Techniques for Dependability
and the DbC/ExecutableSpecs-related stuff is in the papers summarized
below.
The latter paper describes the Wise (Workbench for Interactive
Software Engineering) system which has rudimentary support for DbC. At
some point when I have more time I plan to release the WiseR (the Ruby
prototype of the system) as open-source or even do a FreeRIDE plugin
based on it. Time is a scarce resource though…
Postscript files available on request. Sorry for the plug.
Regards,
Robert Feldt
feldt@ce.chalmers.se
A Theory of Software Development, Technical Report no. 02-22,
Department of Computer Engineering, Chalmers University of Technology,
Gothenburg, Sweden, November 2002.
Abstract:
We present a theory of software development as an incremental learning
process. The focus is on the internal models of the developer. There are
two main ways in which a development process can make progress: by
refining an internal model or by refining an artefact based on an internal
model. Refining the internal models is a prerequisite for being able to
write a concrete specification and program that show acceptable behaviour.
The theory has implications for tools to support software development. By
creating novel test cases they can force the developer to question his
internal models and realize where they are incomplete or incorrect.
An Interactive Software Development Workbench based on Biomimetic Algorithms,
Technical Report no. 02-16, …
Abstract:
Based on a theory for software development that focus on the internal
models of the developer this paper presents a design for an interactive
workbench to support the iterative refinement of developers models. The
goal for the workbench is to expose unknown features of the software being
developed so that the developer can check if they correspond to his
expectations. The workbench employs a biomimetic search system to find
tests with novel features. The search system assembles test templates from
small pieces of test code and data packaged into a cell. We describe a
prototype of the workbench implemented in Ruby and focus on the module
used for evolving tests. A case study show that the prototype supports
development of tests that are both diverse, complete and have a meaning to
the developer. Furthermore, the system can easily be extended by the
developer when he comes up with new test strategies.
On Fri, 25 Apr 2003, Ken Hilton wrote:
Several months ago, I made a posting regarding a possible enhancement to
Ruby to facilitate Design by Contract (DbC). Matz and Justin were kind
enough to reply w/their thoughts and I was curious to know whether there is
any hope for such functionality in any near future release of Ruby.
Ken Hilton wrote:
Several months ago, I made a posting regarding a possible enhancement to
Ruby to facilitate Design by Contract (DbC). Matz and Justin were kind
enough to reply w/their thoughts and I was curious to know whether there is
any hope for such functionality in any near future release of Ruby.
Hi,
Dave did some work on it. You’ll find it @
http://www.pragmaticprogrammer.com/ruby/downloads/dbc.html
Cheers
Stephan
I always saw DBC as the combination of pre-, post-, and loop variable-
conditions. There’s nothing to mandate static, compile time checking, and
the flavour of DBC I’m used to is very much geared towards runtime checks.
There’s no point evaluating a pre-condition unless you’ve been given
something to evaluate, which yells “runtime!” to me, but maybe I’ve just
been using dynamic languages for too long 
Cheers,
Mike
On Fri, 25 Apr 2003, Robert Klemme wrote:
“Ken Hilton” kenosis@attbi.com schrieb im Newsbeitrag
news:xbUpa.606467$L1.172152@sccrnsc02…Several months ago, I made a posting regarding a possible enhancement to
Ruby to facilitate Design by Contract (DbC). Matz and Justin were kind
enough to reply w/their thoughts and I was curious to know whether there
is
any hope for such functionality in any near future release of Ruby.Since ruby is dynamically typed currently I don’t see much chance to have
DBC in ruby. You can’t even fix argument types of methods in the
interface. You can of course do argument (type) checking at runtime, but
there’s not static type information about arguments.
–
Mike Wyer mike@wyer.org www.wyer.org/mike 07974 254007
"I want to die peacefully in my sleep like my Grandfather...
… not screaming and yelling like the passengers in his car"
Static types and contracts are almost orthogonal, since contracts are
concerned with how the code actually behaves. Sure, you don’t have
separate interfaces to define the contracts in, but most of what
contracts provide could be done.
/Anders
— Robert Klemme bob.news@gmx.net wrote:
Since ruby is dynamically typed currently I don’t see much chance to
have
DBC in ruby. You can’t even fix argument types of methods in the
interface. You can of course do argument (type) checking at runtime,
but
there’s not static type information about arguments.
=====
Anders Bengtsson ndrsbngtssn@yahoo.se
Stockholm, Sweden
Gå före i kön och få din sajt värderad på nolltid med Yahoo! Express
Se mer på: http://se.docs.yahoo.com/info/express/help/index.html
“Mike Wyer” mike@wyer.org schrieb im Newsbeitrag
news:Pine.LNX.4.44.0304251128030.1484-100000@hagbard.wyer.org…
Since ruby is dynamically typed currently I don’t see much chance to
have
DBC in ruby. You can’t even fix argument types of methods in the
interface. You can of course do argument (type) checking at runtime,
but
there’s not static type information about arguments.I always saw DBC as the combination of pre-, post-, and loop variable-
conditions. There’s nothing to mandate static, compile time checking,
and
the flavour of DBC I’m used to is very much geared towards runtime
checks.
Hm, I’ve seen parameter types (or call it type constraints a la,
“parameter must be conformant to type X”) as one element of the
preconditions. But then, maybe I’ve used static typed languages too long.
Thinking about this you could have the precondition checking code
somewhere visible near the method signature and have this executed
automatically. Did you check out the implementation by Andrew Hunt
available from the wiki link I posted earlier?
There’s no point evaluating a pre-condition unless you’ve been given
something to evaluate, which yells “runtime!” to me, but maybe I’ve just
been using dynamic languages for too long
Well, some preconditions can be checked at compile time, i.e. if you know
the value that is passed to a method invocation. But generally speaking
you are right.
robert