From: Albert Wagner <alwagner@...>
Date: 2001-08-12T11:12:53+09:00
Subject: [ruby-talk:19566] Re: order and freedom in Ruby (was: Re: Re: the way class variables work)

Just a newbie here, but aren't you talking about  contracts?

On Saturday 11 August 2001 19:15, Chris Uzdavinis wrote:
> Paul Prescod <paulp@ActiveState.com> writes:
> > I'm not sure what you mean. Dynamically typed languages are roughly as
> > old as statically typed languages. I guess it is roughly Lisp versus
> > Fortran. People have indeed built many massive systems in dynamically
> > typed languages. It is arguably easier than in statically typed ones.
>
> Dynamic typing is only a tangent to what I'm talking about.
>
> I'm asking how to deal with dynamic mutation of behavior, the dynamic
> addition and removal of methods from objects.  The dynamic
> changing-the-meaning-of-a-function-call.
>
> Dynamic typing deals with type RESOLUTION.
>
> I'm talking about behavior and type MUTATION.
>
> > > def foo(arg)
> > > # stuff
> > > end
> > >
> > > Now, how can I call foo such that there is no type error?
> >
> > I'll give you back a function:
> >
> > float foo(int b, int c){
> >    return b/c;
> > }
> >
> > How can I call foo such that there is no value error (when C is 0)?
>
> Your question is a diversion.  I'm not asking how to force an errones
> call to succeed.  I'm asking how, given a function (whose behavior may
> change from one call to the next) I can determine what needs to be
> passed in in order to produce a valid call.
>
> The answer to your question is to call foo when c is not zero.
> Otherwise you're simply asking a loaded question.  Your foo has a bug,
> and that is the implementor's responsibility.
>
> The situation I'm talking about is the CALLER's problem, not the
> function implementor's problem.
>
> > I read the documentation for foo. I inspect the implementation of
> > foo etc.  The problem can get even worse:
> >
> > float foo(int *b, int *c){
> >    return *b/*c;
> > }
>
> So your foo requires that its arguments be non-null pointers-to-int,
> with c being a pointer to a non-zero integral value.
>
> Once that is established, that doesn't changed.  It's compiled code,
> and foos implementation doesn't change.  Once you know the
> restrictions on how it works, you can write code that works within
> those restrictions.
>
> Ruby's dynamic method mutation capabilities, means that all bets are
> off.  I could be calling completely different functions from one
> invocation to the next, it can have changing requirements.  Heck, it
> can have requirements that are unique every time the program is run.
>
> I might THINK I know what it does, but I can never know.  I just have
> to hope that no code has actually changed the meaning out from under
> my feet.
>
> > What if b has the "type" NULL instead of the type (int *)? I'll have a
> > type error, right? But the compiler doesn't catch it.
>
> Huh?  NULL is a value, not a type.
>
> > > If foo is dynamically created, it's my code doesn't know anything
> > > about it.  Assuming I have to call it, if I get a TypeError exception
> > > how do I discover what type I should have provided?  I'm not convinced
> > > that there is enough information available to actually infer the type.
> >
> > You seem to want to write programs that dynamically assemble pieces of
> > code that were not tested together and which dynamically reconfigure
> > until they work.
>
> It's an idea.  Considering that Ruby programs are capable of
> dynamically changing, I'm just thinking about dynamic adaptions to
> that change.  I think it's interesting to think about.
>
> Also, you seem to be convinced that testing is sufficient.  Unless
> your tests show 100% coverage of every line of every file that your
> Ruby program uses, you don't know if one of those untested lines may
> change your environemnt and break your code.  Further, even 100%
> coverage doesn't really mean much, since it could be a series of
> calls, or only particular values of certain function calls, which
> trigger the kinds of change that can be destructive.
>
> Finally, I'm thinking about a call to eval, which opens up the world
> to unknown code.  (I know about safe-levels of ruby, and tainted
> objects, but that's a band aid, not a real solution.)
>
> There is no amount of testing that can prove correctness over
> dynamically changing problems.
>
> > I don't see how this is possible in any language! How
> > does Java allow it? How would Java help with the b/c problem? The only
> > way to write code that works with other code, in general, is to
> > communicate with the other author through documentation or through
> > reading their code or something like that.
>
> I think you're missing my point entirely.