[ruby-talk:13687] Re: methods and types

From: "Jish Karoshi" <[e-mail]>
>
> I have been using mostly java for the last 5 or 6 years and did
> C and C++ previously.  I have never used smalltalk.  That might
> explain why I need to ask the following basic question:
> 
> How do you design programs when you can't specify types?  If all
> I can specify in a method definition are the names of the arguments,
> then how does anybody know how to use that method without knowing
> about the implementation of the method?  The same thing goes for
> the return value.  How do I know what I am supposed to send and
> what I can expect to get back unless those types have been announced
> in the method signature or I  understand how the method I want to
> call is implemented?

As one who felt strongly about how beneficial static typing (compile-
time type checking) must be to keeping a whole class of "problems"
out of programs, as recently as a couple years ago . . . . I anticipate
you'll find that, somewhat like 'Hungarian notation', static typing
doesn't really communicate quite as much to the programmer as it is
often credited to.

Even in a statically-typed world, how often does one find oneself not
bothering to look at what kind of object a routine says it wants as a
parameter; but instead just passing in any ol' object type, relying on
a compiler error to inform us about what kind of object the routine
really wants?  Probably we look at the function declaration to see 
what kind of object that method wants to work with.  :)

Consider the following three declarations:

  void moveWidget (Widget& aWidget) {
      // don't look at the implementation yet
  }

  template<class T> void moveWidget (T& aWidget) {
      // don't look at the implementation yet
  }

  def moveWidget(aWidget)
      # don't look at the implementation yet
  end

What kind of object would you supposed we would pass to the last two?

"Well, something that acts like a Widget." would probably be my own
answer.

So it seems we may be now to your question, where it seems you may be
asking: yes, but how do I know if I have something that acts like a
Widget or not, without having to inspect the code of everything that
*says* it wants a Widget, to see what capabilities all this various
code demands of a Widget?  :)

Well, hopefully someone will write a better explanation than mine in
this thread, because my answer is: I don't know.  Only, it doesn't
seem that this is a huge problem (in practice.)  I think one may get
used to thinking in terms of the "protocol" required to support a
certain category of operations on an object. . . . Another thought:
What came first, the Widget or the code that uses it?  Somewhere in
the code, I'd expect to either encounter: the quintessential Widget
class; or, something defining what it means to be "like a Widget" in
the abstract (say an Interface in Java; perhaps a mix-in module in
Ruby?)

Anyway, it's late, I may be rambling.  :)

Here's a link that may be of interest:
http://www.pragmaticprogrammer.com/cgi-local/pragprog?JavaIsUntyped


Regards,

Bill