From: dblack@...
Date: 2003-11-06T12:45:39+09:00
Subject: Re: Managing metadata about attribute types

Hi --

On Thu, 6 Nov 2003, Simon Kitching wrote:

> I don't see why the author of StockItem should even consider the
> possibility that a string could be assigned to cost; that would violate
> the contract of the class, so any program that does so can damn well
> take the consequences :-). The StrictTyping module can enforce this, but
> perhaps does so over-eagerly, as it doesn't allow "duck-typing" ie
> objects which aren't Float objects but do behave like them.

I believe that's by design; as I understand it, the StrongTyping
module performs parameter gatekeeping based exclusively on the
class/module ancestry of an object (the namespaces to which it
belongs, as Rich and Chad were discussing), not on what the object
actually can do.  This means, as you say, that objects which might fit
the bill may not get through, if their class/module ancestry is wrong,
and also that objects which do not fit the bill can get through -- for
example:

  irb(main):014:0> s = "a b c d"
  => "a b c d"
  irb(main):015:0> def s.split; "Don't split me!"; end
  => nil
  irb(main):016:0> s.split
  => "Don't split me!"
  irb(main):017:0> def x(str); expect(str, String);
     puts "Got a String!"; end
  => nil
  irb(main):018:0> x(s)
  Got a String!

This brings up the general point that checking an object's
class/module ancestry doesn't tell you anything about its type (its
interface or behavior or capabilities, or its similarity to other
objects on any of these criteria).  This is definitely an area where
confusion has reigned; pretty much everything I've ever heard
described as "type checking" in Ruby is actually classname or ancestry
checking.  I don't know of any sustained examples of type checking in
Ruby (though there may be some).  In fact, I'm not exactly sure what
it would be, though the thought is intriguing :-)

I think this class/type conflation persists in part because of
the historical circumstance of the existence of the #type method -- a
synonym for #class -- which, I believe, exists only because in earlier
days there were issues with parsing the word 'class' as a method name
(rather than a keyword).  People got used to using 'class' and 'type'
interchangeably.

(#type, I'm happy to say, is deprecated:

  candle:~$ ruby -we '"".type'
  -e:1: warning: Object#type is deprecated; use Object#class

so maybe the distinction will be clearer in the future :-)

Florian Gross was (and maybe still is?) working on an interesting
project which sort of weighted method arguments on various criteria,
not just their module ancestry.  Last time we talked about it, it was
still in the very early/experimental stages, but it was intriguing.


David

-- 
David Alan Black
home: dblack@wobblini.net        # New email address
work: blackdav@shu.edu
Web:  http://pirate.shu.edu/~blackdav