Partial Euphoric Type Checking (Super Duck!?)

[Peter]

> > you see we have a problem here. it doesn't matter what methods are

> > implemented, because '>' for a String and '>' for a Numeric don't DO
> > the same KIND OF thing. the operators are overloaded. so respond_to? isn't
> > enough. we end up having to think about what will be passed to those
> > responding methods as well -- we end up having to ask not only, can you
> > handle the responsibilities? but can you handle the arguments? (sounds like a
> > thread i know ;)

>
> So we'd like the code we write to tell us when we've screwed up, but a
> typing system is basically not smart enough, because type alone does not
> determine functionality.
>
> I guess we're back to unit testing.
>
> Or am I over-simplifying?

My view is that neither testing for the presence of a method with a
certain name, nor doing that as well as testing for type of the
parameters, is a sufficient type check. Then sin example from the pickaxe
shows this: two methods with exactly the same signature in any aspect you
can measure without delving into the code. Still they do different things.
Even if every method does exactly as it promises, you can't find out the
promise by looking at method signatures.

Now this was never a problem in a language like Java, because ancestry
told you about the promises a method makes. OK, promises are meant to be
broken, but even in ruby code it's a problem if a method doesn't do what
the caller expects it to do. Not that Java is ideal, especially the fact
that types and classes are the same, except for interfaces. There are
languages that have two types of classes: abstract ones, providing a
hierarchy of interfaces, and implementation classes providing an
implementation for a set of interfaces. You can't inherit from
implementation classes, you can only include its code (mixin-like). This
is full separation of type and class. And implementing an interfaces holds
a promise as to the methods in it. I think it should be doable in Ruby to
have something like that, adapted to ruby's dynamical context. But it
includes more typing (as in hitting keyboard keys), which is a big
turn-off. But it's self-documenting, which saves some typing to.

Anyway, I'm not contesting that The Ruby Way works. But nobody showed
evidence that The Ruby Way With Optional Interface Checking doesn't work
better, though people tried based on flaws of other languages. Ruby is a
dynamic language, but that doesn't say much about its users. (This is not
an argument, it's applicable to anything, it's a punch line).

Peter

[Austin Ziegler]

On Fri, 21 Nov 2003 23:53:49 +0900, Peter wrote:

> Anyway, I'm not contesting that The Ruby Way works. But nobody
> showed evidence that The Ruby Way With Optional Interface Checking
> doesn't work better, though people tried based on flaws of other
> languages. Ruby is a dynamic language, but that doesn't say much
> about its users. (This is not an argument, it's applicable to
> anything, it's a punch line).

The thing that I fear is that the current proposals for Interface
Checking are ... going to change Ruby for the worse.

I agree with the comments that immutable interfaces are probably a
Bad Thing, and that's a core feature of the current proposals.

Why not consider doing interfaces in Ruby as bundles of DbC
"contracts"[1]? That way, you get *dynamic* interfaces that aren't
necessarily simplistic name-checks, which is what I'm opposed to.

-austin
[1] Thanks, Eivind, for the term
--
austin ziegler * [email]austin@halostatue.ca[/email] * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.21
* 09.56.54

[Alan Chen]

Peter <Peter.Vanbroekhoven@cs.kuleuven.ac.be> wrote in message news:<Pine.LNX.4.44.0311211531540.23782-100000@merlin.cs.kuleuven.ac.be>...

> Anyway, I'm not contesting that The Ruby Way works. But nobody showed
> evidence that The Ruby Way With Optional Interface Checking doesn't work
> better, though people tried based on flaws of other languages.

One problem that I can see is that Optional Interface Check could
impose a significant cost on those who aren't interested in
type-checking. Primarily, integrating type-checking code with
non-type-checking code could be a burden. I really don't want to be
browsing through ruby code libraries thinking "is this a type-checked
library?" Or worse, downloading some ruby code only to find that it
didn't mention that type checking was a core approach of the library.
For these reasons, I think the burden should be on the type-checking
implementors to be able to disable the checking with no or few ill
effects. Hmm, I guess this comment applies slightly more to
interface/inheritance checking systems instead of "method signature"
based systems.

Cheers
-alan

[Sean O'Dell]

On Friday 21 November 2003 11:57 am, Alan Chen wrote:

> Peter <Peter.Vanbroekhoven@cs.kuleuven.ac.be> wrote in message
> news:<Pine.LNX.4.44.0311211531540.23782-100000@merlin.cs.kuleuven.ac.be>...
>

> > Anyway, I'm not contesting that The Ruby Way works. But nobody showed
> > evidence that The Ruby Way With Optional Interface Checking doesn't work
> > better, though people tried based on flaws of other languages.

>
> One problem that I can see is that Optional Interface Check could
> impose a significant cost on those who aren't interested in
> type-checking. Primarily, integrating type-checking code with
> non-type-checking code could be a burden. I really don't want to be
> browsing through ruby code libraries thinking "is this a type-checked
> library?" Or worse, downloading some ruby code only to find that it
> didn't mention that type checking was a core approach of the library.
> For these reasons, I think the burden should be on the type-checking
> implementors to be able to disable the checking with no or few ill
> effects. Hmm, I guess this comment applies slightly more to
> interface/inheritance checking systems instead of "method signature"
> based systems.

Most libraries only expect native Ruby types or their own types. Rarely do
they expect you to construct a type all by yourself, you're usually given a
factory method or a class you can call #new on. So even if they did
interface checking, the compliance would already be there for you. Also, it
doesn't affect your existing code because it's allowed to live alongside
non-interface-checked code.

Sean O'Dell

[Greg McIntyre]

Austin Ziegler <austin@halostatue.ca> wrote:

> Why not consider doing interfaces in Ruby as bundles of DbC
> "contracts"[1]? That way, you get *dynamic* interfaces that aren't
> necessarily simplistic name-checks, which is what I'm opposed to.

I thought of that earlier when I read Sean's proposal however I
dismissed it initially because I thought it would be too much effort.
However I think it's a distinct possibility!

The "Partial Euphoric" type system T. Onoma has put forward seems to be
a little like sets of preconditions tagged with identifiers and later
applied to method paramters.

I see it as a gradient... if you put in no effort, you can have little
typechecking, if you put in a little effort, you can have a bit more,
etc. DbC is way up the deep end of the scale where you put in
substantial effort and receive substantial returns. What's more, I think
it should be up to the Ruby developer how much checking is desired.

On the effort scale, IMO:

No checking << Duck typing == Interface checking based upon method name
+ arity ("organised duck typing"?) << Interface checking based upon
method signature == Type checking in static languages << Interface
checking based upon DbC contracts

(<< means "much more than")

That's just my view of the world, maybe DbC isn't that much effort. It
certainly can give wonderful rewards: very powerful and descriptive
interfaces.

Here's a wild suggestions. What if all these levels could be
incorporated in Ruby as separate, optional, non-conflicting libraries?
Okay, maybe I should go lie down now. ;)

--
Greg McIntyre ======[ [email]greg@puyo.cjb.net[/email] ]===[ [url]http://puyo.cjb.net[/url] ]===

[Peter]

> The thing that I fear is that the current proposals for Interface

> Checking are ... going to change Ruby for the worse.
>
> I agree with the comments that immutable interfaces are probably a
> Bad Thing, and that's a core feature of the current proposals.
>
> Why not consider doing interfaces in Ruby as bundles of DbC
> "contracts"[1]? That way, you get *dynamic* interfaces that aren't
> necessarily simplistic name-checks, which is what I'm opposed to.

I agree. But I would like to see more coming out of this meanwhile long
thread than just the next impasse. That's why I'm trying to help Sean a
bit by keeping him on the true ruby path. And maybe we've finally got
someone who's stubborn enough to give it a real try and put interface
checking to the test. If it changes ruby for the better, that great. If it
only does that for some people, and leaves other people untouched, that's
an addition too. When it changes things for the worse, we can start
arguing again...

Peter

[Peter]

> One problem that I can see is that Optional Interface Check could

> impose a significant cost on those who aren't interested in
> type-checking. Primarily, integrating type-checking code with
> non-type-checking code could be a burden. I really don't want to be
> browsing through ruby code libraries thinking "is this a type-checked
> library?" Or worse, downloading some ruby code only to find that it
> didn't mention that type checking was a core approach of the library.
> For these reasons, I think the burden should be on the type-checking
> implementors to be able to disable the checking with no or few ill
> effects. Hmm, I guess this comment applies slightly more to
> interface/inheritance checking systems instead of "method signature"
> based systems.

As I see it now - for me it is certainly not a settled issue either -
maybe an interface could just give you a convenient way to do respond_to?
checks. And any object could be allowed to "duck type" the interface. But
declaring that a class does implement the interface can serve as
documentation, just like formalizing the respond_to? checks using those
interfaces can. I still like the idea of self-documenting code because
it's harder to get inconsistent. But for that, it would only work really
well if it was a language feature rather as an extension. Especially
since the only way to disable it such that it becomes overheadless
currently is when it is built in, though a feature like :wrap or :pre
could change that.

Maybe what I'm trying to say is that if duck typing is The Ruby Way, then
it can't hurt to have some support for that in Ruby. I guess I'm someone
who's pretty sensitive to the I-have-done-this-before feeling, and when
documenting code or writing unit tests I easily feel like I'm doing
something over and over again when it comes to duck typing - among other
things, but it's about duck typing now. This feeling is what makes me long
for another language each time I learn a new one. But anyhow, like I said,
if duck typing is The Ruby Way, I feel that including support for that on
more levels than we have now does not limit anything but can save (at
least me) some time because some things happen automatically.

Maybe that's just me...

Peter

[Charles Hixson]

Austin Ziegler wrote:

> ...
>
>Why not consider doing interfaces in Ruby as bundles of DbC
>"contracts"[1]? That way, you get *dynamic* interfaces that aren't
>necessarily simplistic name-checks, which is what I'm opposed to.
>
>-austin
>[1] Thanks, Eivind, for the term
>--
>austin ziegler * [email]austin@halostatue.ca[/email] * Toronto, ON, Canada
>software designer * pragmatic programmer * 2003.11.21
> * 09.56.54
>

dbc contracts and unit tests are useful features. Nothing now known
will really solve the problem, but those both ameliorate it. Do be
sure, however, that the dbc contracts are only expensive while
debugging. Because they can be *quite* expensive.