From: Chad Fowler <chad@...>
Date: 2003-11-21T08:41:02+09:00
Subject: Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )

On Fri, 21 Nov 2003, Sean O'Dell wrote:

# On Thursday 20 November 2003 02:40 pm, Chad Fowler wrote:
# > On Fri, 21 Nov 2003, Yukihiro Matsumoto wrote:
# >
# > #
# > # In summary, "interface checking" (not static type checking we had seen
# > # before) is a good thing.  But I'm not sure it's good enough to put in
# > # the future Ruby, where API document might help, and where we have two
# > # challenges above.
# > #
# >
# >
# > matz, how do you define "interface"?  In sean's case, class and/or module
# > were sufficient to define interface.  This is majorly what I take issue
# > with.  If "interface" is really a collection of "respond_to?"
# > requirements, then I can start to stomach the idea of it being added to
# > Ruby (I believe you were proposing something similar in your RubyConf
# > presentation).  Have a look at Sean's RCR at RubyGarden.  It includes the
# > following:
# 
# No, class/module were NEVER enough.  I've made two proposals (one RCR and post 
# new idea posted here), and neither of them used class/module except as a 
# proposed way to indicate an interface was implemented.  But class and module 
# has nothing, at its heart, to do with it, I just put them up there to show 
# one way to do it.  It was primarily an "interface id tagging system" and the 
# tags could be stuck onto objects in any fashion: by the class they came from, 
# by an explicit declaration, through a method call, or through some sort of 
# object-to-interface mapping system.
# 
# The point of the RCR was, there was no interface definition, it was just an 
# interface id tag system.  Class and module were just one way of showing how 
# it could work.
# 
# Read on, and let's skip the RCR I proposed.  I see now that people want 
# something more fulfilling than a simple empty promise than the interface id 
# tagging system was providing.
# 
# > <sean>
# > class MyClass
# >   end
# >
# > The above class implicity declares "I implement the MyClass interface."
# > Pretty simple.
# > </sean>
# >
# > He goes on to say the same re: inheritance and module inclusion.
# >
# > Do you consider these to define "interface"?  I don't.
# 
# True, my RCR did not define an interface, and by design.  I was under the 
# impression that type checking was unwanted and so I came up with a very loose 
# design.  It was intentional.
# 
# Read my post in this newsgroup/mailinst list titled "New Type Checking System 
# Idea."  This, I think, is much closer to what people are asking for.
# 

As you understand now, my problem with your old proposal was primarily 
that it provided an empty promise.  I feel like that would have muddied 
things up for both people like me, who have come from the static typing 
world and slowly understood how to work in the dynamic way, and for people 
who actually want something that makes them feel safer.

Your new proposal is less ambiguous, and therefore (IMO), better.  I still 
don't like it, but I'll save the reasons for a later post.


# As an aside, I am curious why you and Ziegler and several others participate 
# in this way.  Rather than beating people up for their ideas, why don't you 
# point out how they could be improved, or come up with your own ideas?  I 
# can't deny that no one liked my RCR, but in the process I really feel 
# attacked, and badly.  Can't you guys figure out some other way to export your 
# ideas rather than holding them private and then just swatting away anything a 
# person has to say on the subject?  What are your ideas for something like 
# this?  Post them up ... let's hear a proposal.  I promise, I will be kinder 
# to you than you were to me.
# 

I attempted to point via Glenn Vanderburg's suggestion to Objective C.  
I mentioned several times and in several ways that "respond_to?" is more 
important than any kind of "kind_of?" (no pun intended), which was an 
attempt at constructive criticism.  It only seemed to add fuel to the 
fire, unfortunately.  I'm sorry we hurt your feelings.  I never want 
people to feel badly.  But, in retrospect, you did a little swatting yourself 
(and early on).  (Before many of us jumped in with the tone you're 
referring to).  It's really a matter of how you choose to interpret the 
tone of a message. 

I don't believe any of us have held our views in private and waited to 
swat.  I believe that the majority of people who come into the Ruby 
community looking for this kind of functionality are fresh-out-of-Java and 
looking to make Ruby fit the Java way of thought.  I experienced the same 
thing myself 3 years ago, when I started programming in Ruby.  But, over 
time I let Ruby shape my way of thinking.  I was bothered by this nagging 
desire to implement interfaces which are supported via "contracts" that 
can be snapped together like lego bricks (hi Shashank!).  But, I let 
myself set that nagging feeling aside for a while and just go with the 
flow.  Eventually, I found that in going back to Java or C#, I was often 
seriously annoyed by the typing systems these languages had to offer.  And 
more often than not, I find the interface checking concept to actually eat 
up my productivity.

I do still construct interfaces and do things contractually when I program 
in Java.  But sometimes something wonderfully dynamic pops out (at least 
in as much as this is possible in Java).  And, I think, "Wow.  I never 
would have thought of that before."  

So, now about these proposals you would rather see us come up with: 
my proposal is that we fully drop the type-checking idea.  This is my idea 
for something like this.  "respond_to?" is enough.  My motivation and 
rationale are that we may provide so much of a crutch to new Rubyists that 
they will never learn the lessons that Ruby has to teach, and they will 
never program in The Ruby Way.

A somewhat happy compromise would be to create a mechanism for automating 
respond_to? checking (and probably even "declaration").  But I don't think 
it should look at *all* like classes or modules.  That would further 
confuse an already confused generation of Ruby programmers (especially 
those to come).  I don't know what it should look like, but that's largely 
because I don't see a need for it, and therefore don't sit around 
imagining what it should look like.  I know I don't want Ruby to look like 
this:

public class Person implements Animal
{
   public static String greet(Animal a) throws IDoNotLikeYouException
   {
     ...
   }
}

And, your most recent proposal, while an improvement over the previous one 
still comes uncomfortably close.

Anyway, I think this thread has gone on way too long * 2.  It's obviously 
a topic that both new and old Rubyists get passionate over.  I'm looking 
forward to seeing where Matz takes it.  Judging by what he said in his 
RubyConf presentation, I'm sure it will be the best of both worlds.

Chad