On Wednesday 19 November 2003 03:35 pm, Austin Ziegler wrote:
> On Thu, 20 Nov 2003 06:08:30 +0900, Sean O'Dell wrote:
> > On Wednesday 19 November 2003 12:42 pm, Maik Schmidt wrote:
> >> Sean O'Dell wrote:
> >>> and doesn't have to be dynamically loaded via "require."
> >>
> >> Why should everybody pay for it?
> >
> > Because that's where the hit should occur. If you don't need it,
> > don't use it.
>
> Again: why should everybody pay for it? It's a runtime cost, not a
> design time cost.

Because it's a feature I feel Ruby should have.

> > Something this big really ought to have a stamp of approval. But
> > that's a stretch; it doesn't look like Matz wants anything of this
> > nature in Ruby anyway.
>
> Not quite true. Matz recognises the need for something like it (it's
> in his Ruby2 presentation). At the beginning of my plunging into
> this round of the discussion, I admitted the need for a few classes
> of applications. But design-time/compile-time stuff isn't one of
> those classes.

What is -w for then?

> Static typing helps the compiler, not the developer.

What part of "I don't want static typing" didn't you understand?

Have you even read my RCR yet?

> >> That's not true in any case. If checking for an implemented
> >> interface was sufficient, then the interface would have to look
> >> like a Java interface or something similar. The questionable
> >> feature that you are asking for implies IMHO a lot more changes
> >> than we all see now. And I cannot see a real benefit.
> >
> > It requires NO CHANGES. It's entirely optional. It's just a
> > declaration of an interface.
>
> If it isn't like the Java/C# interface, then it's less "useful" than
> what we have now in Ruby. Why? Because then it's a runtime cost
> added to the program but it's merely a signal to the programmer.

You do realize we're talking about probably 20 lines of C code, plus whatever 
it takes for Matz to add the syntactic sugar to parameters.

> To go back to your example from a different post:
>
>   class MockRuwiki
>     interface Ruwiki
>   end
>
> This adds overhead (executing "interface Ruwiki") without enforcing
> that MockRuwiki actually implements the interface. If I did:
>
>   def accept_ruwiki(foo as Ruwiki)
>     foo.backend
>   end
>
> Then I'd happily accept your MockRuwiki but then I'd blow up because
> you violated the contract anyway. How is this better than:
>
>   def accept_ruwiki(foo)
>     foo.backend
>   end
>
> Seriously.

You are so stuck on "the cost" of this.  It's such a tiny amount of code in 
exchange for the ability to warn each every developer who calls your code 
that you expect a certain interface from their object.  

It's a LOT better.  For you, who knows the contract, no, it's the same thing.  
For a person using the library trying to pass in an unsuitable object, where 
the documentation is lacking (and that's MOST of the code out there, MOST 
code is completely undocumented) it results in an extremely useful and 
time-saving error message.

	Sean O'Dell