"stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )<[e-mail]>

Hi --

On Tue, 18 Nov 2003, Thien Vuong wrote:

> [e-mail] wrote:
> >
> > The system you're describing -- one-to-one, immutable mapping of
> > methods in a class with methods of which that class's instances are
> > capable -- is only proven and established in languages where it's
> > enforced, which don't include Ruby.  What you're saying is sort of
> > like saying: using a keyboard to generate musical notes is proven and
> > established, so let's add keyboards to violins.  (Actually it's more
> > like saying: let's play the violin by using its keyboard; to which I
> > say: what keyboard? :-)
> >
>
> I don't think I'm describing a one-to-one, immutable methods ...
> I'm aware that the class could be extended/modified, just as
> individual method could be modified too.  I'm only searching for a way
> to ensure the needed behaviour are implemented - "when such a need
> arise".

Class name checking doesn't ensure needed behavior.  Actually, let me
say first that while I have a lot to say here, I don't mean to single
out your post or pounce on your wording; what's happening is that I'm
growing concerned because it seems that we're going through a flurry
of popularity of #is_a?-based checks which pretend to be type checks
but are not (some done raw and some done using wrappers like
"StrongTyping", all of which are actually checking class and module
names rather than type).  I fear that this is starting to have the
cumulative effect of truncating people's understanding of objects,
dynamism, and type in Ruby.  I'd like to truncate the truncation :-)

When one acts as if class name is an indicator of interface, one is in
effect saying to the object: "You are an ABC, and on the basis of
knowing only this, I am able to predict your behavior!"  In other
words, what's going on in these class-checking practices is not type
checking or strong typing but, in fact, _stereotyping_: that is, the
belief that one can infer what an object can and will do from what it
"is".  Needless to say (I hope), I mean this on a very local level; I
do not mean that people who habitually perform these specious "type"
checks are stereotyped in their social thinking.  In fact, quite the
opposite: I'm going on the assumption that we all recognize the
frailty and brittleness of social stereotyping, and I'm suggesting
that stereotyping Ruby objects -- inferring the "can" from the "is" --
is, in its much smaller domain, equally frail and brittle.

>  From my limited understanding, there are 2 types of checking that could
> be used: respond_to? (duck-typing?) and kind_of?  By Ruby dynamism,
> none of the current method could guarantee the behaviour.  So we're
> have some choices:

"Duck typing" is not essentially linked to any particular method;
specifically, it is not essentially about calling respond_to?  Ruby
gives you duck-typed objects -- that is (in my paraphrase), objects
whose types are inferential, consisting of the sum of their behaviors
at a given point in program execution.  You can deal with these
duck-typed objects in various ways, of which respond_to? is one.

> - Respond_to? is fine.  It works for a large class of problems where one
>     or 2 methods are good enough to define the behaviour.  In fact, for
>     those, a type/class contortion is overkill and having this capability
>     on Ruby is great.
> - kind_of?, which to me, is a combination of respond_to? with the
>     expected behaviour of the class.  It comes at a cost that the object
>     does need to be in the correct class hiearchy.

kind_of? has no connection to respond_to? except that you learn
whether or not the object responds to "kind_of?" :-)  So the cost you
pay -- that the response to kind_of? has to pass some test of
name-membership -- in most cases gets you little or nothing.

> - A very flexible behaviour model based on respond_to?  This is great,
>     but requires extra coding, could be buggy, and have
>     performance impact.
>
> None of the methods, however, would guarantee behaviour - It more or
> less a higher/lower degree of assurance :).

Absolutely -- and respond_to? gets you a lot closer than kind_of?
since it tells you what's going on as close to the moment of
method-calling as possible.  (One can take the position, as some have
in earlier discussions of this, that code which fails to supply
objects whose types are represented by their classes -- and which
therefore might benefit from the use of respond_to? -- is by
definition 'broken'; but this is of course a circular argument, and
one which simply tosses a great deal of Ruby's power and flexibility
into the trash for no good reason.)

> Assumes, that a design has to do this checking
> at some point, a reasonable implementation would have to be a
> combination of system design to control the checking points, a set of
> checkin of type (either respond_to or kind_of), and a set of
> decent test cases.
> >
> > These things aren't at war with each other; it's a dynamic,
> > object-oriented language.  I'd advise against looking at the dynamism
> > of Ruby objects as "extra".  It's present from the ground up, and goes
> > absolutely straight to the heart of the "type != class" principle in
> > Ruby.
> >
> Kind of agree - type is not class.  Just as class != static - it's only
> a set of qualified behaviour.
>
> But it does not have to be different either.  As I don't know of a
> "generally" better way to check for type/behaviour (when needed) -
> it should be part of the design toolset until there is a better one :).
> I'll be glad to drop it all if I know a good way - really.

It doesn't have to be different, but it *does* have to be -- will
always be -- *potentially* different, because this is Ruby :-) And,
when you get right down to it why not?  People sometimes make it sound
like Ruby objects' interfaces were made mutable to tempt us, and our
ability to act like they're not mutable is a test of our strength of
character.  I just don't see the point.

Anyway, I don't know that there is one way to check type -- that is,
there's no one way to guarantee correct behavior on the part of Ruby
objects.  (I'm interested in what Matz is thinking about for 2.0, but
it's only been mentioned in a very preliminary way.)  Checking the
class name with is_a? or "StrongTyping" doesn't tell you anything
about type or behavior, unless you constrain your programming habits
as described above (and never use external libraries or code written
by people who choose to embrace the dynamism of Ruby objects).  I
would say, keep exploring, think of ways to design your code for the
kind of scaleability where, as far as possible, objects are asked to
do things and can do them (or take appropriate action where they
can't).


David

-- 
David Alan Black
home: [e-mail]        # New email address
work: [e-mail]
Web:  http://pirate.shu.edu/~blackdav