From: Ryan Pavlik <rpav@...>
Date: 2003-11-08T10:25:13+09:00
Subject: Re: Managing metadata about attribute types

On Sat, 8 Nov 2003 09:45:24 +0900
"John W. Long" <ng@johnwlong.com> wrote:

> Ryan,
>
<snip>
> 
> An intriguing argument. By far the best that I have heard for Strong
> Typing.
>
> I do wonder: what is really gained by Strong Typing? Are better error
> messages the only advantage?

Well, the main advantage I have gained, aside from debugging bonuses,
is the ability to ask what types something wants.  This is what
started the discussion in the first place, I believe.

> An experienced ruby programmer will see a method-not-defined error
> message and know that it means the wrong object was probably passed
> in to his method. This kind of error message certainly throws
> beginning Ruby programmers for a loop, but is it really a weakness
> of the language?

Actually simply seeing the error is often not much use.  For instance,
in Mephle I have defined a whole set of classes that allows one to
treat HTML as a widget set.  For instance:

    table  = Table.new
    table << Row["a", "b", "c"]

       :

    puts table.to_s(renderer)

Often, widgets are passed around and used deeply within the code.
Consider the following mistake:

    def add_extra_row(r)
       :
       table << w
       :
    end

    add_extra_row Object.new
    
When the widget is actually "rendered" via #to_s, you might see
something like this:

    NoMethodError: undefined method `rowsize' for #<Object:0x4019f23c>
       /path/to/Table.rb:500
       :
       :

This shows that a problem occurred in the code---we don't have
something that's a row---but it doesn't show you where the _actual_
error occured---when someone passed you an Object instead of a Row.
The ST module allows you to catch the culprit immediately.

> If Strong Typing is an advantage how does it help experienced Ruby
> programmers? Do you find that it saves a significant amount of time?
> Does it help you catch errors you normally would not have known
> existed? Does it encourage the right programming habits? If it can
> be demonstrated that it does these things, perhaps it should be
> incorporated into the language.

The error above is a decent example.  For me it's not really about the
time saving primarily, it's about the ability to query parameter
types, but the time saving has helped.

However I am not asking or expecting this be integrated into the
language.  It's obvious many people dislike it.  I think it would be
nice if things were typed like in the snipped example though.  Perhaps
this is something I could add to the module.

I love the dynamicism of Ruby.  It has allowed me to make this module
that does what I want---something that would be considered a builtin
feature in many other languages---without having to modify the core
language.  I would rather see ruby's core remain as simple as
possible.

> I like the clean syntax, but I can't help feeling like I'm looking
> at code someone with a strong background in statically typed
> languages would write.

I have a background in statically-typed languages and
dynamically-typed languages.  Both of these are orthogonal to strict
type checking.  For instance, Common Lisp (which no-one can argue is
static anything) allows one to specify parameter types in much the
same way as this module.  These are used by some compilers for
optimization purposes.  They are also optional, and they do not
diminish the dynamicism of the language.

> How can you prevent someone from using Strong Typing in the wrong
> way?

I don't believe this is the right question.  You can't prevent someone
from using something in the wrong way.  I tried to demonstrate this
with the ruby-goto module, which abuses exceptions and blocks to
implement labels and goto in ruby.  The trick is to make it so there
is no incentive to do things the wrong way, rather than prevent them.
Thus I expect (hope!) no one will ever seriously use ruby-goto,
because there is no incentive to do so.

Similarly with ST.  You can build a totally unstructured class
hierarchy which repeatedly breaks the API at every subclass and makes
the module useless.  However there is no incentive to do so.

> Is there a way to accomplish this through a different
> implementation/syntax?

It depends on what you mean by "this"... it could probably be
implemented differently and maybe with different syntax.  I could
probably have documented types with something like MetaTags alone.

Actually, I now recall another reason for not doing so.  Mephle had a
few requirements I needed to resolve.  Type documentation was one.
Mephle provides remote object handling, and is built on the concept
that users will directly manipulate objects.  Both remote code and
users have access to objects.  "Type safety" takes on a whole new
meaning---remote access means potential for malicious abuse, so even
with limited permissions, it may be possible to pass a
maliciously-constructed object over the network.  With the
StrongTyping module that is no longer possible.

(For the record, ST does not verify object content, but that's not
what this is about.  Nor can you pass an object to the server of a
class the server does not know about.  The problem is when the server
knows about two objects:

    class Privileged
       def foo
          # privileged operation
       end
    end

    class Unprivileged
       def foo
          # operation anyone can call
       end
    end

    class SomeoneElse
       def blah(x)
          :
          x.foo
          :
       end
    end

Now if the remote end passed the server a Privileged object, bad
things would happen.  Yes, you may be able code around this
specifically in every case.  But it's quicker and more reliable to let
the system handle it for you.)

-- 
Ryan Pavlik <rpav@mephle.com>

"If we can hear your internal monologue, then it *isn't*." - 8BT