> On Fri, 28 Jan 2005, Austin Ziegler wrote:
>> ...I hate any language that requires me to type stuff just to
>> help the compiler...
> Me too. This is why I'm proposing that we have systems where the
> compiler figures this out for us.

>> static typing and such type checking is NOT for us, the
>> programmers, but for the compiler.
> I'm not quite sure what you mean by "static typing," but type
> checking is for us, the programmers. One of the things that is
> good about Ruby is that it does thorough type checking--it is a
> strongly typed language.

Variables (labels) are untyped, though. Most people who want some
sort of type checking, including your erstwhile correspondent
Transami, end up wanting something that looks an awful lot like
class checking on variables (e.g., variables that only accept
objects of a given type/class; homogenous containers, etc.)

>> ...the moment that some fool library writer decides that they
>> want something that *is* an IO object, it will no longer be
>> possible to pass in a StringIO object (it doesn't inherit from
>> IO, and IO isn't a module) or even a specially modified Array or
>> String or some other object.
> 
> Any "fool library writer" can do that now:
> 
>      raise "wrong type" unless arg.class <= SomeClass
> 
> I agree doing that would be silly. But this has no relevance; I'm
> talking about types, not classes.

Okay, so define an object's type. See, this is where things get
complicated -- it's *hard* to pin down an object's type in a
language as dynamic as Ruby. For some methods, I require that the
object provided have #<< defined; for others it's something else. I
have gone away from pre-checking this[1], and there's really no way
that any sort of heuristic can be built for it, either -- at least
not one that performs faster than just running the code. Now, if you
wanted to talk about something in Ruby that caches execution
information and uses that to analyse the best execution paths and
increase type safety through repeated runs, I can agree -- but
you'll still have at least one run that's not optimized in any way.

> Given that you are objecting to the direction I'm proposing whilst being
> unaware that you're agreeing with me on key points and possibly even
> unaware that you're already using type checking, I would suggest you go
> do some research on type systems before commenting further.
> 
> Here's the start on your research: find out why Class.class method
> is deprecated in favour of Class.type.

Actually, in Ruby, it's the other way around. #type has been
deprecated in favour of #class. They were synonymous. The "type" of
an object is something more nebulous, and it's much harder to
determine; as I said, an Object (modified), an Array, a String, or a
StringIO object can all act like an IO object -- and the only way
you can check that is by knowing what methods are required by the
entire method.

> It's quite common that someone who doesn't understand an advanced
> langauge feature (usually because it's not in any of the languages
> he uses) will object to it through ignorance, only to be unable to
> live without that feature once he starts using it. Garbage
> collection was once considered slow, inefficient and unreliable.
> Would you like to take GC out of Ruby?

Actually, I'm objecting to your asinine arrogance -- suggesting that
without this, Ruby will be a second-class language and that you do
know better.

You don't. Why don't you actually try reading some of the older
discussions on types and classes and variants of type checking and
type inference before you start going on about this.

Because classes and objects aren't closed in Ruby, it becomes
computationally expensive (prohibitively so) to try to have the
compiler or interpreter to do a lot of this "programmer protection"
stuff. That's just reality. There are things that can be done to
improve performance, but it's more of a histogram analysis than a
single run performance improvement.

-austin
[1] One of the things that I do is check this during the assignment
    of adapters. That is, when you write:
      Text::Format.new.hyphenator = Text::Hyphen.new
    You'll be guaranteed that the #hyphenator object of the
    anonymous Text::Format object will respond to #hyphenate_to(). I
    don't actually verify during the hyphenation call in
    Text::Format that your hyphenator is a real hyphenator -- so if
    you circumvent my uniform access method and do:

      Text::Format.new.instance_variable_set("@hyphenator", Object.new)

    You're going to get an ugly exception at runtime, not at
    initialization.
-- 
Austin Ziegler * halostatue / gmail.com
               * Alternate: austin / halostatue.ca