Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )

On Thursday 20 November 2003 03:41 pm, Chad Fowler wrote:
>
> 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.

There are ways to demonstrate that while maintaining an air of dignity in 
participation.  Let's drop it though.  I think just by mentioning it, things 
have straightened out a bit, so let's just work civilly on this.  If anyone 
chooses to play rough from here on out, let them be noted and ignored.

> 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.

I look forward to your comments in more detail.

> 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 didn't see this as a proposal or a refinement of one, but perhaps there is 
something to what you're saying.

Looking at respond_to? over kind_of?, I agree, when there is nothing better.  
respond_to? tells you that something exists, which says something far more 
definite than kind_of? really does (although you can make assumptions).

But there's more you COULD know, and it in the end what we get will probably 
appear more like kind_of? than respond_to?.  An interface is very closely 
related to a class, and the test for whether or not an object implements an 
interface will probably be something like implements?, which is a broad 
statement about an objects abilities, much like kind_of? causes people to 
make broad assumptions about object abilities.

Interfaces are described in a similar way to classes, and quite often, in 
practice, classes and interfaces end up being synonymous.  One without the 
other is an exception rather than the rule, at least.  So while I agree that 
respond_to? is more informative than kind_of?, in the end, a good interface 
query system is going to look a heck of a lot like kind_of?

> 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.

Here's where we agree.  I think Java's use of interfaces is a waste of time in 
MANY places, but not every place.  The right tool for the right job.  I hate 
that Java won't let me just do stuff.  I hate that Ruby won't let me enforce 
types.  Why?  Because in both cases, I'm not given much of a choice.

> 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."

Me too!  But instead of switching languages, what if you could develop 
something in Ruby like usual, then as a project started to get larger and 
more complicated, or as people were added to the project who might not fully 
understand all your classes, wouldn't it be nice to say "okay kids, before 
you go muddying up this project, here's a couple rules for you.  never pass 
anything but this type here.  and this type here."  So except for the places 
where you think you ought to provide a little guidance, leave the rest of it 
wide open as usual.

> 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.

The problem I have with automating respond_to? is it sounds like something 
that would happen constantly at runtime when type checking was needed.  That 
places more burden on the engine than I think people would be happy with.  I 
personally wouldn't be thrilled with all that activity at each call to a 
method with type requirements.

In my last proposal, you can ignore it and develop like usual, or you can get 
REALLY STRICT like Java and go nuts with it, or you can just sort of apply it 
here and there as needed.

I think at first, something like this would look scary but I think after 
awhile a pattern of usage would settle in and people would find what's 
comfortable.

> 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.

To me, it's only recently that I've had any epiphanies about how it might 
work, so it's still a pretty new discussion to me.  I still want to hammer 
out some ideas, because I really think there could be a win-win way to do 
this.

	Sean O'Dell