[ruby-core:32632] Re: Proposal for Optional Static Typing for Ruby

  Hi Joshua,

On 9/28/2010 10:36 PM, Joshua Ballanco wrote:
> I intended no offense via omission in not quoting your next example. I merely wanted to point out that testing against a specific class is not a very good paradigm to follow. I realize that an awful lot of Ruby code that you might find today includes just this sort of anti-patern, but I don't think that is a legitimate excuse. I think it's a symptom of poor design.
Poor design can be a valid argument. However, it's hard to define whose 
design is the "poor" one when we're talking about a multi-paradigm 
language. A duck-typed system is not always the "right" design just 
because the target language is Ruby. There are many cases of good design 
in Ruby that use perfectly standard class-based systems with very little 
duck-typing-- I don't think it's fair to call them poor just because 
they don't use duck-types.
> In this specific case, I would argue that a #run method which either takes a pre-constructed object *or* parameters to construct the object for you is not very well designed. These are two different tasks. The should be handled by two different methods. I realize that this is, essentially, what you're proposing with annotating the argument types, but I wonder why you think that annotating types is better than just creating two different methods with different names?

Using a separate name is not always viable, and, in fact, often yields 
messy APIs. The benefits of reusing a common name is that you have fewer 
"verbs" to deal with, and your API "Just Works" for the given input. 
Overloading is a pretty common idiom in many languages, especially Ruby. 
Just about every Ruby API (including Ruby's own core APIs) does this, so 
let me pre-empt you by saying it's not "poor design" to do this. The 
only difference is that in Ruby, it's all handled manually by the 
programmer, and the only reason this is so is because the interpreter 
could not distinguish method definitions without the type information.

But let me answer your question more directly by offering you a better 
example, one straight out of ruby-core's libraries. Consider String#[] 
(http://ruby-doc.org/core-1.8.7/classes/String.html#M000700), aka. 
String#slice, which has a whole host of overloads, 6 of them to be 
exact. This method would be a perfect candidate for actual overloading 
support. Do you think String#slice should be split up into #slice_index, 
#slice_range, #slice_regexp, etc.? I wouldn't think that would be a good 
API design.

> Object-oriented != Class-oriented
>
> If you're requiring specific classes, then you're not truly duck-typed. To be clear, I'm not attempting to make any judgement about doing things one way or the other, but I think we must be very clear about what it is that we are trying to accomplish. If you want a class-based type system, say so! But this is not the same thing as a duck type system.

Why do we have to choose? Why do we *have* to use duck typing? Ruby 
allows us both. The point here is that type annotations could allow 
either or neither, but also improve the way which we do some regular 
everyday things. I'm not trying to make Ruby less dynamic, or less 
duck-typed-- that part should be made clear. I'm simply trying to point 
out that type annotations could be used to simplify many existing and 
widely used idioms. Whether they're valid idioms is a discussion for 
another thread, IMO.
> The reason that I didn't pick on your second example with the method requirement is that I feel like this is better handled in a formal design-by-contract syntax than as a type-signature, but that's an opinion.
The way I see it, these type annotations *are* a DbC syntax. Why do you 
see it as otherwise?

> The more fundamental issue that we still haven't addressed is that when you say:
>
> 	def run(thing: #start)
> 	  thing.start
> 	end
>
> You're making the implicit assumption that #start will always do what you expect. What makes Ruby difficult is not the lack of type annotations or class-based vs duck typed, it's the fact that the duck-typing is unreliable! Depending on what's going on in code you 'require', you have no idea if String#length will do what you expect, or that 'require' itself hasn't been redefined.
Weren't you just all about the duck-typing, and now you're calling them 
unreliable and difficult? :) In any case, I don't think that's very 
relevant. It doesn't matter "what" #start will do, the type information 
here simply says that it should respond to a method, any method, named 
#start. It wouldn't be the goal of a duck-type-based annotation to 
actually *statically* type anything. The type annotation would exist for 
documentative purposes, but could also be used by the compiler at 
run-time, or by tooling for some data-flow analysis.

Perhaps there's a misunderstanding of the proposal here, or at least 
mine. It would be impossible to have a fully statically typed Ruby 
program if type information is only provided optionally unless *all* 
types were defined; but let's be realistic, that won't happen. 
Therefore, this isn't *really* static typing, it's simply type 
annotations. I would see this being used, as I just said, at run-time or 
by tools-- very rarely, if ever, at compile-time-- at least certainly 
not if duck-typed annotations were used. I'm not too sure if that's what 
was originally intended to be proposed by this thread, but that's how I 
would see it.

- Loren