From: Robert Klemme <bob.news@...>
Date: 2004-05-18T18:23:51+09:00
Subject: Re: How to duck type? - the psychology of static typing in Ruby


"Marek Janukowicz" <childNOSPAM@t17.ds.pwr.wroc.pl> schrieb im Newsbeitrag
news:slrncajk30.4g8.childNOSPAM@child.ha.pwr.wroc.pl...
> On Tue, 18 May 2004 08:48:04 +0200, Robert Klemme wrote:
> >> >> Broken record time:
> >> >>
> >> >> The problem with all of these solutions is that they are
discovered at
> >> >> run-time.  I find it increasingly irritating when I have to debug
> >> >> typing errors by running an application that takes some time to
get to
> >> >> the error.  Enough of those times, the error is a typing error, so
that
> >> >> I've been harping lately about wanting a duck-type checker hooked
in to
> >> >> "ruby -c".
> >> >
> >> > I guess due to the nature of Ruby it's impossible to check this
without
> >> > actually executing the code because of Ruby's dynamic typing.
> >> >
> >> > If you want compile time type safety you need to use a statically
typed
> >> > language.  Both types of programming languages have their pros and
> > cons -
> >> > but you can't get both at the same time.
> >>
> >> What about Objective-C? It has static typing (with regular pointers)
and
> >> kind of dynamic typing ("id" type). Maybe Ruby should have similar
> >> capability? Or maybe I just told something really stupid?
> >
> > I alway have to look up definitions...
> >
http://en.wikipedia.org/wiki/Dynamic_typing#Static_vs._dynamic_type_checking
> >
> > Unfortunately I'm not familiar with Objective C so I can't judge on
that.
>
> I cannot say I know Objective C well too, but I get some basic concepts.
>
> > From what I've seen so far I'd assume it's similar to Java which is
regarded
> > as statically typed although you have access to type information at
runtime
> > (as seems to be the case with Objective C).  But the crucial part is
that
> > you declare types (of variables, of method arguments) in code and
these
> > types are checked by the compiler.
>
> But the feature I described in my previous post has no equivalent in
> Java - I'll try to explain it (I may be very wrong, so anyone knowing
> Obj-C better please correct me):
>
> In Obj-C, when you create a variable to hold a pointer to an object of
> class Object, you have 2 choices:
>
> Object *obj;
> id obj;
>
> the second pointer is "typeless", because it can point to an object of
> any class. I wonder if similar mechanism could be useful in Ruby.
>
> > Ruby does not do this (as does Lisp, although it seems there are some
> > optimization type hints).  So without these declarations it's
difficult to
> > do type verification at compile time without code execution.  To
introduce
> > this wuold be a major change in the language and break lots of code.
If you
> > would allow for typeless and typed method arguments at the same time,
you
> > would increase interpreter complexity by orders of magnitude and code
would
> > be a real mess.  I don't think, it's a good idea.
>
> I'll try to explain my idea in more detail. I suggest that one could put
> optional type information when declaring the variable, eg:
>
> def some_method ( String str, second_param )
>
> do |Array ar, smth, Fixnum int|
>
> etc.
>
> So basically, current typeless declaration would become something
> similar to Obj-C's id, and new typed one would be similar to Obj-C's
> Object*.
>
> Note I don't mean to change (dynamic) method dispatching here - I just
> wish Ruby had some mechanism for type checking on variable assignment,
> so I don't get enigmatic error messages deep inside a library I use (but
> I didn't write). Of course such mechanism would not prevent some runtime
> errors (given you can remove method from an object), but it would surely
> be very useful (at least for me).
>
> In other words, this feature would be equivalent of 'strongtyping'
> library, just with better syntax and compile-time checking (to avoid
> runtime overhead).

But there's a whole lot of problems waiting:

 - You need return type declarations (at least optional)
 - What do you do if you invoke a method with a required parameter type bu
t your value resides in some typeless var?
 - You'll likely and up casting values all the time => errors here can
only be detected at runtime
 - Internal handling of references must be completele changed.
 - What do you gain by type info if any instance is free to override
methods defined in the class at will?
etc.

Although I can see the benefit for some users, I'm still not convinced
that this is a good idea, that it fits Ruby well and / or that this will
show up in Ruby in the near future.  After all, it will make a lot of
Ruby's simplicity go away.  And I don't think, Matz wants to go into that
direction.

Regards

    robert