From: Trans <transfire@...>
Date: 2006-04-03T05:08:44+09:00
Subject: Re: Typed Parameters


Bill Kelly wrote:
> From: "Trans" <transfire@gmail.com>
> >
> > I've creted my method to deal with Integer's
> > that's what I designed it to do. You want to send it a Watchamacallit?
> > Why? You really think it's going to work? Do you know enough about the
> > method I wrote to think that using it with Watchamcallit's will be all
> > that beneficial?
>
> I don't see why you would need to bear the burden of worrying
> about this.  Let it be my problem, if I feel the need to use
> your library in a way you hadn't anticipated.  :)
>
> > If a Watchamacallit isn't Integery enough to be a
> > subclass of one or be coerced into one, what makes you think it SHOULD
> > work? What if you change Watchamacallit later on? What if my mehtod
> > changes later on?
>
> Hmm... This is starting to remind me of public vs. private
> methods.  Ruby lets me call a private method on one of your
> classes, but I have to do so explicitly - and if your class
> internals change later on and my call to that private method
> breaks, I won't be surprised.  I took the risk deliberately.
>
> Maybe if parameter types could be specified and enforced in
> some way where I, the library user, would have a means of
> calling the method that would bypass those checks?  So that,
> most of the time, I pass in an Integer and everyone's happy.
> But if I decide that passing in a Watchamacallit best meets
> my needs, then there should be a way to call your method and
> bypass the type checks - even if I have to be explicit about
> it.
>
> I guess what I'm saying is IF there were typed parameters,
> I think there should be a way around the checks, similar to
> how we can call private methods when we really need to.

That's a fair assessment. And really it's probably enough to do:

  class Watchamacallit
    def to_int ; self ; end
  end

Wouldn't that be a fair way of saying somthings Integery?

I also would like to point out that this idea of contract parameters
isn't just a means of code reliability. People make good point when
they argue that unit tests can go along way toward  mooting this need
while improving production performance. But, they are also useful for
dividing up code base on parametric concerns. To be able to do

  def foo( x : String )
    ...
  end

  def foo( x : Int )
    ...
  end

seems to me a much more readible and versitile way of handling the
cases, irregardless of any contractual beneifits.

T.