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

ruby-talk
1

dblack@wobblini.net wrote:

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.

Uh… If we’re getting there the equivalent argument would be
“respond_to?” would not tell you anything except that it respond to
“respond_to?” :). Unless we agree on some basic contract that a method
need to satisfy (knowing that it could be changed - mind you), it is
pointless to go one way or another.

  • 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

Do you mean because we tend to call respond_to? closer to usage point
than kind_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.)

I could see that one could reasonably take that position in any
particular design. The software structure is created by specification
and design to attain specific requirements - and one could “choose”
to limit the flexibility/power to obtain other more desirable goals
for that piece of software - ie. performance, contract guarantee,
no runtime error, etc… Flexibility and power, as much as I
like it, almost never enters in an application requirements :).

That is not to say that other ways is necessarily wrong - but it
certainly is within that “chosen” framework.

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

I’m trying. But I find existing Ruby facility as good enough - until
Matz amazes us again with new features :).

Regards

2

[Apologies to anyone whose threading is getting messed up by the
appearance and disappearance of those long message id strings… I’m
not sure where they came from.]

Hi –

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.

Uh… If we’re getting there the equivalent argument would be
“respond_to?” would not tell you anything except that it respond to
“respond_to?” :). Unless we agree on some basic contract that a method
need to satisfy (knowing that it could be changed - mind you), it is
pointless to go one way or another.

OK, let me rephrase that one :slight_smile: The thing you need to know is the
object’s interface – which, this being Ruby, has the potential to
change. respond_to? gives you some of that information, very close to
the moment of calling a method. kind_of? doesn’t. Therefore,
kind_of? is more remote from the problem than respond_to?

Mind you, I’m not trying to advocate calling respond_to? before every
other method call. There are many other things one can do to
accomodate and leverage the inferential typing of Ruby objects,
including exception handling and unit testing. I also agree with Jim
Weirich that what’s really at stake here is not a large likelihood
that, say, a String won’t respond to #split when you think it will
(though that is certainly always possible in a language that does not
have a tight coupling between class and type), but rather the
potential cutting off of interesting design possibilities. Not that
every time one writes a method one has to come up with an interesting
design :slight_smile: But still, I think Jim is right that that’s where the
rewards lie.

David

···

On Wed, 19 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

3

Actually, kind_of? is far more informative. kind_of? indicates that it
belongs to a pre-described interface (a contract), with a fixed collection of
methods with parameters which are also known. respond_to? only tells you an
object has a method of a certain name. In another post I just made, I gave
this example:

obj.respond_to?(:open) => true

…so how do you call open? You don’t know. Now this:

obj.kind_of?(:socket) => true

…now you know it responds to open, close, read, write, select, etc. and you
know what parameters they take. By only testing respond_to? you only know
that a method is present, but you don’t know what parameters it takes.

Sean O'Dell
···

On Wednesday 19 November 2003 03:55 am, dblack@wobblini.net wrote:

On Wed, 19 Nov 2003, Thien Vuong wrote:

Uh… If we’re getting there the equivalent argument would be
“respond_to?” would not tell you anything except that it respond to
“respond_to?” :). Unless we agree on some basic contract that a method
need to satisfy (knowing that it could be changed - mind you), it is
pointless to go one way or another.

OK, let me rephrase that one :slight_smile: The thing you need to know is the
object’s interface – which, this being Ruby, has the potential to
change. respond_to? gives you some of that information, very close to
the moment of calling a method. kind_of? doesn’t. Therefore,
kind_of? is more remote from the problem than respond_to?

4

Hi –

Uh… If we’re getting there the equivalent argument would be
“respond_to?” would not tell you anything except that it respond to
“respond_to?” :). Unless we agree on some basic contract that a method
need to satisfy (knowing that it could be changed - mind you), it is
pointless to go one way or another.

OK, let me rephrase that one :slight_smile: The thing you need to know is the
object’s interface – which, this being Ruby, has the potential to
change. respond_to? gives you some of that information, very close to
the moment of calling a method. kind_of? doesn’t. Therefore,
kind_of? is more remote from the problem than respond_to?

Actually, kind_of? is far more informative. kind_of? indicates that
it belongs to a pre-described interface (a contract), with a fixed
collection of methods with parameters which are also known.
respond_to? only tells you an object has a method of a certain name.
In another post I just made, I gave this example:

A Ruby module or class is neither a contract, nor a fixed collection.
I really don’t think, for example, that what Betrand Meyer meant by
“design by contract” was Ruby classes :slight_smile:

What you’re doing is pressing the closest thing Ruby has to something
that looks like the kind of type-checking you want (i.e., kind_of?)
into service as a type check, which it isn’t.

Quite honestly, the part I don’t get about all this is: why? It’s not
a type check; it is not at all rigorous; and believing in it involves
sweeping under the carpet one of the central design features of Ruby.

David

···

On Thu, 20 Nov 2003, Sean O’Dell wrote:

On Wednesday 19 November 2003 03:55 am, dblack@wobblini.net wrote:

On Wed, 19 Nov 2003, Thien Vuong wrote:

–
David A. Black
dblack@wobblini.net

5

Not in Ruby, it doesn’t. #kind_of? tells you that it has a
particular name in its ancestry. Nothing more, nothing less.
Treating a name as a contract is improper, because that’s not the
case at all.

-austin

···

On Thu, 20 Nov 2003 02:51:02 +0900, Sean O’Dell wrote:

Actually, kind_of? is far more informative. kind_of? indicates
that it belongs to a pre-described interface (a contract), with a
fixed collection of methods with parameters which are also known.

–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.19
* 15.50.40

6

Uh… If we’re getting there the equivalent argument would be
“respond_to?” would not tell you anything except that it respond to
“respond_to?” :). Unless we agree on some basic contract that a
method need to satisfy (knowing that it could be changed - mind you),
it is pointless to go one way or another.

OK, let me rephrase that one :slight_smile: The thing you need to know is the
object’s interface – which, this being Ruby, has the potential to
change. respond_to? gives you some of that information, very close to
the moment of calling a method. kind_of? doesn’t. Therefore,
kind_of? is more remote from the problem than respond_to?

Actually, kind_of? is far more informative. kind_of? indicates that
it belongs to a pre-described interface (a contract), with a fixed
collection of methods with parameters which are also known.
respond_to? only tells you an object has a method of a certain name.
In another post I just made, I gave this example:

A Ruby module or class is neither a contract, nor a fixed collection.
I really don’t think, for example, that what Betrand Meyer meant by
“design by contract” was Ruby classes :slight_smile:

A contract is any interface, and a Ruby class is an interface. True, a Ruby
class isn’t the definition of a contract, but any OO class serves the
function well enough. Despite Ruby’s flexibility, at any given point, a
class implements an interface. It can be extended or changed, but it
definitely describes an interface.

What you’re doing is pressing the closest thing Ruby has to something
that looks like the kind of type-checking you want (i.e., kind_of?)
into service as a type check, which it isn’t.

Yes, but no one cares if an object being passed in is really of a certain
type, all they care about is if it has the interface their method(s) need. I
don’t want a type check, I just want some enforcement that an interface
exists where I need it.

Quite honestly, the part I don’t get about all this is: why? It’s not
a type check; it is not at all rigorous; and believing in it involves
sweeping under the carpet one of the central design features of Ruby.

Because no type checking at all causes non-descriptive errors when an object
is passed to a method (2 of 1 parameters?) which expects it to have certain
methods which takes certain parameters. Either way, an error occurs, but
with some form of type checking, the programmer gets a much clearer picture
of why they can’t pass in a particular object to a method without at least
some modification.

Example: you get an “object does not the :socket interface.” You then say to
yourself: “Ah! This library wants something like the Socket class…okay, I
can fake that!”

It’s just informational. It’s just for the purpose of speeding up development
and making the code a little more robust through a good report of what is
going wrong when someone passes in an object that can’t be used by the
method. It doesn’t prove that an object correctly implements an interface,
and the object can definitely break the interface, but the facility would be
there for programmers who can make use of it. For those that tend to break
interfaces when programming rather than use them properly, there are always
QA jobs. =)

Sean O'Dell
···

On Wednesday 19 November 2003 10:27 am, David A. Black wrote:

On Thu, 20 Nov 2003, Sean O’Dell wrote:

On Wednesday 19 November 2003 03:55 am, dblack@wobblini.net wrote:

On Wed, 19 Nov 2003, Thien Vuong wrote:

7

I agree. My intention is to elevate us to something more than respond_to? and
kind_of? calls. I misused kind_of?, sorry. I meant to use an imaginary
method that says “this object implements this interface.”

Sean O'Dell
···

On Wednesday 19 November 2003 12:53 pm, Austin Ziegler wrote:

On Thu, 20 Nov 2003 02:51:02 +0900, Sean O’Dell wrote:

Actually, kind_of? is far more informative. kind_of? indicates
that it belongs to a pre-described interface (a contract), with a
fixed collection of methods with parameters which are also known.

Not in Ruby, it doesn’t. #kind_of? tells you that it has a
particular name in its ancestry. Nothing more, nothing less.
Treating a name as a contract is improper, because that’s not the
case at all.

8

Hi,

A contract is any interface, and a Ruby class is an interface. True, a Ruby
class isn’t the definition of a contract, but any OO class serves the
function well enough. Despite Ruby’s flexibility, at any given point, a
class implements an interface. It can be extended or changed, but it
definitely describes an interface.

A class has interface; a class can be used as interface (by set of its
methods); but it should not be checked by kind_of? or anything based
on inheritance, just because it hinders flexibility of dynamic typing
so much; remember StringIO or tempfile examples.

It’s just informational. It’s just for the purpose of speeding up development
and making the code a little more robust through a good report of what is
going wrong when someone passes in an object that can’t be used by the
method. It doesn’t prove that an object correctly implements an interface,
and the object can definitely break the interface, but the facility would be
there for programmers who can make use of it. For those that tend to break
interfaces when programming rather than use them properly, there are always
QA jobs. =)

I admit type checking can gain you something, at the cost of
flexibility, which I don’t want to pay in Ruby. If you prefer static
typing to dynamic typing, it’s OK, there so many statically typed
languages out there. Go ahead.

						matz.
···

In message “Re: “stereotyping” (was: Re: Strong Typing (Re: Managing metadata about attribute types)” on 03/11/20, “Sean O’Dell” sean@celsoft.com writes:

9

A Ruby module or class is neither a contract, nor a fixed
collection. I really don’t think, for example, that what Betrand
Meyer meant by “design by contract” was Ruby classes :slight_smile:
A contract is any interface, and a Ruby class is an interface.
True, a Ruby class isn’t the definition of a contract, but any OO
class serves the function well enough. Despite Ruby’s flexibility,
at any given point, a class implements an interface. It can be
extended or changed, but it definitely describes an interface.

A class defines a collection of methods that could be called an
interface. However, an instance of a Ruby class need not implement
that interface. Again, a pathological example:

f = File.open(“foo.txt”)
class << f
undef write
end

The object referenced by f is a File, but it doesn’t support
#write.

What you’re doing is pressing the closest thing Ruby has to
something that looks like the kind of type-checking you want
(i.e., kind_of?) into service as a type check, which it isn’t.
Yes, but no one cares if an object being passed in is really of a
certain type, all they care about is if it has the interface their
method(s) need. I don’t want a type check, I just want some
enforcement that an interface exists where I need it.

Which #kind_of? does not do. Why do you want or need that
enforcement? When I first used dynamic languages, I wanted them to
act like the static languages that I worked with, but I quickly grew
out of it. I briefly experimented with #kind_of? checking in Ruby,
but found few cases where I really needed it.

-austin

···

On Thu, 20 Nov 2003 03:52:30 +0900, Sean O’Dell wrote:

On Wednesday 19 November 2003 10:27 am, David A. Black wrote:
–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.19
* 15.53.42

10

Hi,

···

In message “Re: “stereotyping” (was: Re: Strong Typing (Re: Managing metadata about attribute types)” on 03/11/20, “Sean O’Dell” sean@celsoft.com writes:

I agree. My intention is to elevate us to something more than respond_to? and
kind_of? calls. I misused kind_of?, sorry. I meant to use an imaginary
method that says “this object implements this interface.”

This is all cause of this long thread. I’m glad that we’ve finally
found out the point. Then see [ruby-talk:85641].

						matz.
11

qyyOn Thu, 20 Nov 2003, Sean O’Dell wrote:

···

A contract is any interface, and a Ruby class is an interface. True, a Ruby

class isn’t the definition of a contract, but any OO class serves the

function well enough. Despite Ruby’s flexibility, at any given point, a

class implements an interface. It can be extended or changed, but it

definitely describes an interface.

Because no type checking at all causes non-descriptive errors when an object

is passed to a method (2 of 1 parameters?) which expects it to have certain

methods which takes certain parameters. Either way, an error occurs, but

with some form of type checking, the programmer gets a much clearer picture

of why they can’t pass in a particular object to a method without at least

some modification.

Example: you get an “object does not the :socket interface.” You then say to

yourself: "Ah! This library wants something like the Socket class…okay, I

can fake that!"

Or how about:

blah.rb:7:in example_method': undefined methoddrive’ for “car”:String
(NameEr
ror)
from blah.rb:10

Is there ever a chance you wouldn’t understand what that means?
Personally, I would see that message, open up blah.rb, look at line 10

Or

It’s just informational. It’s just for the purpose of speeding up development

and making the code a little more robust through a good report of what is

going wrong when someone passes in an object that can’t be used by the

method. It doesn’t prove that an object correctly implements an interface,

and the object can definitely break the interface, but the facility would be

there for programmers who can make use of it. For those that tend to break

interfaces when programming rather than use them properly, there are always

QA jobs. =)

Sean O’Dell

12

Hi,

A contract is any interface, and a Ruby class is an interface. True, a
Ruby class isn’t the definition of a contract, but any OO class serves
the function well enough. Despite Ruby’s flexibility, at any given
point, a class implements an interface. It can be extended or changed,
but it definitely describes an interface.

A class has interface; a class can be used as interface (by set of its
methods); but it should not be checked by kind_of? or anything based
on inheritance, just because it hinders flexibility of dynamic typing
so much; remember StringIO or tempfile examples.

But again, that flexibility is LOST when you have to pass an object to a
method that REQUIRES it to behave a certain way. The flexibility is already
gone; it wasn’t eliminate by a language quirk, it was eliminated by the need
of the method being called.

It’s just informational. It’s just for the purpose of speeding up
development and making the code a little more robust through a good
report of what is going wrong when someone passes in an object that can’t
be used by the method. It doesn’t prove that an object correctly
implements an interface, and the object can definitely break the
interface, but the facility would be there for programmers who can make
use of it. For those that tend to break interfaces when programming
rather than use them properly, there are always QA jobs. =)

I admit type checking can gain you something, at the cost of
flexibility, which I don’t want to pay in Ruby. If you prefer static
typing to dynamic typing, it’s OK, there so many statically typed
languages out there. Go ahead.

No, I prefer BOTH. There are times when dynamic typing works, and times when
you need enforcement of an interface.

I’m clear on the subject of dynamic typing, and I’m not an advocate for static
typing. Being a strong advocate for one or the other is foolish, in my
opinion. Both are useful, and both can be employed here, so I BEG you to
please employ SOME form of built-in interface checking. Having absolutely NO
mechanism leaves people who need to check for certain methods and parameters
hanging in the wind.

I’m only talking about checking that a certain interface is present. Just for
the purpose of providing an informative error message when an object which
cannot fulfill the needs of a method is passed. Right now, it just explodes
with an ugly message about something that happened deep in the called method.
Something more informative would go a LONG way.

Reconsider, Matz.

Sean O'Dell
···

On Wednesday 19 November 2003 11:05 am, Yukihiro Matsumoto wrote:

In message “Re: “stereotyping” (was: Re: Strong Typing (Re: Managing > metadata about attribute types)” > > on 03/11/20, “Sean O’Dell” sean@celsoft.com writes:

13

A Ruby module or class is neither a contract, nor a fixed
collection. I really don’t think, for example, that what Betrand
Meyer meant by “design by contract” was Ruby classes :slight_smile:

A contract is any interface, and a Ruby class is an interface.
True, a Ruby class isn’t the definition of a contract, but any OO
class serves the function well enough. Despite Ruby’s flexibility,
at any given point, a class implements an interface. It can be
extended or changed, but it definitely describes an interface.

A class defines a collection of methods that could be called an
interface. However, an instance of a Ruby class need not implement
that interface. Again, a pathological example:

f = File.open(“foo.txt”)
class << f
undef write
end

The object referenced by f is a File, but it doesn’t support
#write.

I agree. I don’t advocate STRONG checking, just simple declarations that
“this object implements this interface” and it does, it does, if it doesn’t,
it doesn’t.

What you’re doing is pressing the closest thing Ruby has to
something that looks like the kind of type-checking you want
(i.e., kind_of?) into service as a type check, which it isn’t.

Yes, but no one cares if an object being passed in is really of a
certain type, all they care about is if it has the interface their
method(s) need. I don’t want a type check, I just want some
enforcement that an interface exists where I need it.

Which #kind_of? does not do. Why do you want or need that
enforcement? When I first used dynamic languages, I wanted them to
act like the static languages that I worked with, but I quickly grew
out of it. I briefly experimented with #kind_of? checking in Ruby,
but found few cases where I really needed it.

That’s good, because you have no choice. Doing kind_of? isn’t terribly
flexible. It requires inheritance, and that means people have to write
abstract classes in order to allow people to re-implement classes. I don’t
advocate inheritance as a means to communication conformity with an
interface. Just a keyword that says “I implement this interface” is
perfectly acceptable.

I would also wager that if it were available, and powerful, you would return
to at least a little bit of type checking. People only miss something for so
long before they get used to not having it. Of course you don’t miss it now.

Sean O'Dell
···

On Wednesday 19 November 2003 01:03 pm, Austin Ziegler wrote:

On Thu, 20 Nov 2003 03:52:30 +0900, Sean O’Dell wrote:

On Wednesday 19 November 2003 10:27 am, David A. Black wrote:

14

Excuse that last post. It was an abandoned one that ended up getting
accidentally sent.

Chad

···

On Thu, 20 Nov 2003, Chad Fowler wrote:

qyyOn Thu, 20 Nov 2003, Sean O’Dell wrote:

# A contract is any interface, and a Ruby class is an interface. True, a Ruby

# class isn’t the definition of a contract, but any OO class serves the

# function well enough. Despite Ruby’s flexibility, at any given point, a

# class implements an interface. It can be extended or changed, but it

# definitely describes an interface.

# Because no type checking at all causes non-descriptive errors when an object

# is passed to a method (2 of 1 parameters?) which expects it to have certain

# methods which takes certain parameters. Either way, an error occurs, but

# with some form of type checking, the programmer gets a much clearer picture

# of why they can’t pass in a particular object to a method without at least

# some modification.

# Example: you get an “object does not the :socket interface.” You then say to

# yourself: "Ah! This library wants something like the Socket class…okay, I

# can fake that!"

Or how about:

blah.rb:7:in example_method': undefined methoddrive’ for “car”:String

(NameEr

ror)

from blah.rb:10

Is there ever a chance you wouldn’t understand what that means?

Personally, I would see that message, open up blah.rb, look at line 10

Or

# It’s just informational. It’s just for the purpose of speeding up development

# and making the code a little more robust through a good report of what is

# going wrong when someone passes in an object that can’t be used by the

# method. It doesn’t prove that an object correctly implements an interface,

# and the object can definitely break the interface, but the facility would be

# there for programmers who can make use of it. For those that tend to break

# interfaces when programming rather than use them properly, there are always

# QA jobs. =)

# Sean O’Dell

15

Yes, because I don’t know what sort of object has the #drive method. It’s not
an object I am familiar with, and I don’t even know what #drive is supposed
to do. An error message that like just says to me “something is very wrong,
and you don’t know what.”

Opening up the source and looking at the line won’t necessarily tell you
anything. You could be there for awhile looking around trying to figure out
what the code does. It’s not an efficient way to debug at all.

Sean O'Dell
···

On Thursday 20 November 2003 08:58 am, Chad Fowler wrote:

qyyOn Thu, 20 Nov 2003, Sean O’Dell wrote:

A contract is any interface, and a Ruby class is an interface. True, a

Ruby # class isn’t the definition of a contract, but any OO class serves
the # function well enough. Despite Ruby’s flexibility, at any given
point, a # class implements an interface. It can be extended or changed,
but it # definitely describes an interface.

Because no type checking at all causes non-descriptive errors when an

object # is passed to a method (2 of 1 parameters?) which expects it to
have certain # methods which takes certain parameters. Either way, an
error occurs, but # with some form of type checking, the programmer gets a
much clearer picture # of why they can’t pass in a particular object to a
method without at least # some modification.

Example: you get an “object does not the :socket interface.” You then

say to # yourself: “Ah! This library wants something like the Socket
class…okay, I # can fake that!”

Or how about:

blah.rb:7:in example_method': undefined method drive’ for “car”:String
(NameEr
ror)
from blah.rb:10

Is there ever a chance you wouldn’t understand what that means?
Personally, I would see that message, open up blah.rb, look at line 10

16

I’m clear on the subject of dynamic typing, and I’m not an advocate for static

typing. Being a strong advocate for one or the other is foolish, in my

opinion. Both are useful, and both can be employed here, so I BEG you to

please employ SOME form of built-in interface checking. Having absolutely NO

mechanism leaves people who need to check for certain methods and parameters

hanging in the wind.

···

On Thu, 20 Nov 2003, Sean O’Dell wrote:

If you really need something that bad, how about respond_to? If you need
something more robust, then there’s types.rb by Eivind Eklund.

17

Hi,

A class has interface; a class can be used as interface (by set of its
methods); but it should not be checked by kind_of? or anything based
on inheritance, just because it hinders flexibility of dynamic typing
so much; remember StringIO or tempfile examples.

But again, that flexibility is LOST when you have to pass an object to a
method that REQUIRES it to behave a certain way. The flexibility is already
gone; it wasn’t eliminate by a language quirk, it was eliminated by the need
of the method being called.

I’m not sure what you mean by “flexibility LOST”. In your scenario in
[ruby-talk:85611], certainly it is much easier to tell that your
library is requiring Socket interface, but without that kind of
interface check, no flexibility is lost, it’s little bit hard to find
out the semantics.

Maybe we are referring different “flexibility”. Mine is the one that
allows replacing IO by StringIO. Currently we have no language
support to check nor enforce them, but it’s still possible, not lost.

I’m only talking about checking that a certain interface is present. Just for
the purpose of providing an informative error message when an object which
cannot fulfill the needs of a method is passed. Right now, it just explodes
with an ugly message about something that happened deep in the called method.
Something more informative would go a LONG way.

Reconsider, Matz.

Reconsider what? I didn’t tell you any decision yet. I’m still
the level of seeking what you mean.

						matz.
···

In message “Re: “stereotyping” (was: Re: Strong Typing (Re: Managing metadata about attribute types)” on 03/11/20, “Sean O’Dell” sean@celsoft.com writes:

18

A class has interface; a class can be used as interface (by set
of its methods); but it should not be checked by kind_of? or
anything based on inheritance, just because it hinders
flexibility of dynamic typing so much; remember StringIO or
tempfile examples.
But again, that flexibility is LOST when you have to pass an
object to a method that REQUIRES it to behave a certain way. The
flexibility is already gone; it wasn’t eliminate by a language
quirk, it was eliminated by the need of the method being called.

This argument is circular.

I’m only talking about checking that a certain interface is
present. Just for the purpose of providing an informative error
message when an object which cannot fulfill the needs of a method
is passed. Right now, it just explodes with an ugly message about
something that happened deep in the called method. Something more
informative would go a LONG way.

Static typing in Ruby carries too high a performance price, because
everything (including class and method definitions) are executed
at runtime.

Far better to have an interface publication mechanism than static –
or “strong” typing.

-austin

···

On Thu, 20 Nov 2003 04:37:50 +0900, Sean O’Dell wrote:

On Wednesday 19 November 2003 11:05 am, Yukihiro Matsumoto wrote:
–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.19
* 16.05.20

19

Nobody likes undescriptive error messages. You’re asking Ruby to do
something about them, at a cost. I prefer to believe that the cost
should be on the library developer, who wishes to make life easier for
his clients.

class LibraryClass
def library_method
# code …
rescue SpecificError
# handle it
rescue => err
raise LibraryError, “library_method failed: #{err.message}”
end
end

Granted, it doesn’t often happen in real life, but it is better if the
library author is putting some thought into the user experience,
rather than feeling like he’s jumping through hoops to keep an
interface-checker happy. A frustrated developer probably won’t
produce much code; in that case, at least we’d have less cryptic error
messages, I suppose :slight_smile:

I’m not completely unsympathetic to what you’re saying. In fact, I’d
like to read a detailed RCR.

Cheers,
Gavin

···

On Thursday, November 20, 2003, 6:37:50 AM, Sean wrote:

I’m only talking about checking that a certain interface is present. Just for
the purpose of providing an informative error message when an object which
cannot fulfill the needs of a method is passed. Right now, it just explodes
with an ugly message about something that happened deep in the called method.
Something more informative would go a LONG way.

20

I don’t advocate inheritance as a means to communication
conformity with an interface. Just a keyword that says “I
implement this interface” is perfectly acceptable.

I’ve already addressed the uselessness of this. This could also be
implemented outside of the Ruby core – even as a C extension.

I would also wager that if it were available, and powerful, you
would return to at least a little bit of type checking. People
only miss something for so long before they get used to not having
it. Of course you don’t miss it now.

I don’t miss it now because I am currently working with three
different languages on concurrent projects. Delphi (Object Pascal)
is strongly/strictly typed, and it’s really infuriating because I
can’t just write what I want to do; I have to type everything,
too. Visual Basic for Applications is optionally typed, but is much
easier to use if you do type variables. Ruby, on the other hand,
allows me to write the code that I want without having to worry
about typing at all.

The only place where I can foresee needing a typing mechanism in
Ruby is when I look at wrapping methods in SOAP or other RPC
mechanisms.

-austin

···

On Thu, 20 Nov 2003 06:29:12 +0900, Sean O’Dell wrote:

austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.19
* 18.42.48