Strong Typing (Re: Managing metadata about attribute types) <Pine.LNX.4.44.0311171402340.1133-100000@ool-4355dfae.dyn.optonline.net>

ruby-talk
1

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? :slight_smile:

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”.

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.

···

From my limited understanding, there are 2 types of checking that could

2

let me put my 2eurocent…

a model I’d like to see is:
(for #1)
type hints in method arguments:
def m(String s, b)

at compile time ruby would work like putting an extra
a.kind_of? String
at tht top of m().

(for #2)
a new Kernel method like
def m(a,b)
type_check(a)

the type_check would work like:
“hey, compiler, each time you see ‘a’ responding to :metod
put an additional a.respond_to? :metod at the top of m()”

Obviously if we could find a method name withless than 7 letters
everybody would start to use it.

btw with some black magic we could even have a better

def m(TypeCheck a,b)

…
Anyway this mail was just to ask: how is the #3 model you’re proposing
supposed to work?

···

il Tue, 18 Nov 2003 06:06:18 GMT, Thien Vuong tvuong@comcast.net ha scritto::

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.
3

Hi –

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? :slight_smile:

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 :slight_smile:

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?” :slight_smile: 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 :slight_smile: 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

···

On Tue, 18 Nov 2003, Thien Vuong wrote:

dblack@wobblini.net wrote:

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

4

Class name checking doesn’t ensure needed behavior. […]

It certainly doesn’t. That doesn’t mean that there aren’t times when
name/ancestry checking isn’t useful. Or that “publishing” a method’s
signature isn’t (at times) useful. Note: I’m not changing my
position in this debate – I still think that, based on my last two
years of experience with Ruby, ancestry checking is of extremely
limited utility.

The main place that I use ancestry checking at this point is when
dealing with Ruby’s built-in types – Hash, String, and Array – and
then only when I need to distinguish between types that have
identical method names but subtly differing semantics (e.g.,
Hash#each and Array#each). (The other place that I use it is when I
have a custom type that I absolutely want to be used. See Ruwiki and
Ruwiki::Config for an example.)

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 […]

In some ways, this is a good thing – it generally means that we
have new faces coming in :slight_smile:

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”.

I like this term. A lot.

[…]

One of the things that I’d like to see is perhaps a change to
#respond_to? so that it’s like this:

class Object
alias_method :orig_respond_to?, :respond_to?

def respond_to?(symbol, arity = nil)
  if arity.nil?
    orig_respond_to? symbol
  else
    (orig_respond_to? symbol) && (method(symbol).arity == arity)
  end
end

end

It won’t help in cases as was posted (e.g., accepts one argument of
varying types that you may want to behave differently), but I think
that Ara Howard’s recommended technique in [ruby-talk:85479] is
probably better in the specific posted case.

-austin

···

On Wed, 19 Nov 2003 06:07:13 +0900, dblack@wobblini.net wrote:

On Tue, 18 Nov 2003, Thien Vuong wrote:

dblack@wobblini.net wrote:
–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.19

                                     * 00.59.45