From: Chris Uzdavinis <chris@...>
Date: 2001-08-12T06:43:56+09:00
Subject: [ruby-talk:19548] Re: order and freedom in Ruby (was: Re:  Re: the way class variables work)

David Alan Black <dblack@candle.superlink.net> writes:

> Hello --
> It's interesting in this connection that you say, "It's wishful
> thinking to assume two objects with the same "base class" have
> anything in common whatsoever, aside from that base class."  I
> completely understand what you mean, in terms of Ruby's programming
> facilities.  But it has a sort of ominous sound, as if the code might
> change itself when your back is turned.  I wonder if that's actually
> true in some situations :-)  And whether, in other situations, it's a
> matter of decision-making, rather than wishful thinking.

It could happen, if you take user-supplied input and mix that with an
'eval' statmement, then suddenly you no longer have control of what
your program does. :)

> There is nothing about Ruby that I do not want to understand and
> possibly use.  I am *not* making some kind of case for pretending that
> Ruby is a traditional OO language.  I'm just working toward a view
> that comprises the various, ummmm, facets of Ruby.  (Or interfacets.)

I find it hard to stop thinking in terms of C++ and overriding virtual
functions, etc.  But that just dosn't seem to be the way to design
code in ruby, for all the peviously mentioned reasons.

I am still trying to figure out how one can write non-trivial
applications in Ruby, since the interfaces can dynamically change, and
you can't find out until runtime if your code has type-errors.

What I don't know very well is how to recover.  Given the dynamic
nature of Ruby, we should be able to calculate the missing types and
add them as necessary and try again.  However, normal error-correction
logic usually applies toward values, not types.  I don't know if this
kind of computing has been done enough to have a satisfactory general
solution. 

Since functions are objects, it seems reasonable to be able to ask a
function object "before I call you, what requirements must my
parameters satisfy?"

I'll give you a function:

def foo(arg)
# stuff
end

Now, how can I call foo such that there is no type error?  Let's say
that if there is an error, I can try again with a different argument
that (hopefully) works, as many times as necessary until I get it
"right." Since there can be an infinite number of types (not hard at
all in Ruby!) if I don't have context, it's certainly plausible to
think that brute force would never find the right type to pass into
foo.

It wants something, but won't tell me what it wants.  I could have a
conversion error, or a missing interface piece (it does tell me that,
based on the exception type) and the message contains in a string some
information that a programmer can read and figure out.  But what seems
to be lacking is information for the program ITSELF to scan the
exception object and have enought enformation to make the proper
changes.


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.

But I'm interested to hear what others think.

-- 
Chris