From: Thien Vuong <tvuong@...>
Date: 2003-11-18T15:07:17+09:00
Subject: Re: Strong Typing (Re: Managing metadata about attribute types) <Pine.LNX.4.44.0311171402340.1133-100000@ool-4355dfae.dyn.optonline.net>



dblack@wobblini.net 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".

 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:

- 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.
- 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 :).

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.

I don't advocate type checking much in either case.  It is a performance
killer.  I would rather have all my data/objects pre-qualified already
at admittance into the system and just assume that all are correct
and able to behave themselves.  However, at the qualification points,
some good checking capability is needed - and IMHO both methods are
needed presently.

Cheers.

>