From: Mathieu Bouchard <matju@...>
Date: 2005-04-03T01:35:34+09:00
Subject: Re: Hash::MixIn and Python style Object#dict


On Sat, 26 Mar 2005, gabriele renzi wrote:
> Mathieu Bouchard ha scritto:
> > MetaRuby (http://artengine.ca/matju/MetaRuby/) provides that, with
> > examples implementing #undo/#redo, BitArrays, InstanceVariablesHash,
> > MethodsHash, FileAsString, ProcAsArray, ... And those examples are all
> > very short.
> yes, I know about metaruby but I supposed that it did not work with ruby 
> 1.8. Anyway IIRC your metaruby has one thing I disliked,
> since it does not provide a fine grained functionality splitting, I 
> mean, there are HollowIO and HollowHash instead of 
> Input+Output+Seekable+whatever and Map+EnumerableMap+whatever.
> I may recall wrong, though.

From the source,

  module SimpleIOP
    include Readable, Seekable, Writable
    module Contract; include ::Contract

but this might be something I changed after 0.7 (?). There is no split of
HollowIO into HollowReadableIO, etc, though.

However I do not know what's the difference between a Map and an
EnumerableMap as I can't think of a situation where it would be useful to
not define each_key, especially as it tends to be required for a lot of
Hash's functionality.

Similarly there is no distinction between ReadWriteHash and ReadOnlyHash
because common practice in Ruby is different: instead it is expected that
there will be #freeze and #frozen? and that exceptions will be thrown in
the cases where a write will be refused.

> why those were bad name?

"Hollow" isn't quite as good as "Shallow" in the spatial metaphor domain,
as (almost all of) the Simple interfaces are not intended to be used
directly by the user, so it's better to think of a hole inside
(shallow) than a hole on (hollow).

> FWIW I found names like SomethingP *crazy* the first time I read the 
> code, but now I think of them  as lispy things and I can accept them :)

It's Lispy in the sense that Lisp also uses suffixes (p,q,f,!,?) but
MetaRuby's P is quite different from Lisp's P. I only use suffixes when i
want to have, for example, both an "interface" Foo, a "contract" Foo, a
"class" Foo, ... and i don't want to give them long boring names.

> But I wonder: why both you and florian considered the need to have 
> contracts for this mixable things?

Because it helps distinguish responsibility in case of incorrect
behaviour, so that a bug can be located more easily. There's a similar
argument in favour of type-checking in general.

A way of working that many duck-typers have adopted is to just ignore
those things, so that all failures happen at the lowest possible level
instead of the highest possible one, producing error messages that are
meaningless in terms of the highest-level. Somehow they treat this as a
nonissue (and I don't want to speculate on why that is).

You wouldn't believe how many bugs in HollowArray (etc) I have catched by
just running contracts *and* unit-tests together at once. This is another
usual no-no, that is, most people polarise themselves as using one
technique or the other, but few accept to use both, with the notable
exception of Andy Hunt. I don't know whether he uses both at the _same_
time though. (note: i missed most of the last few years of ruby-talk so
maybe things have changed since)

> I used to love this, and being scared from mixins like Enumerable wich 
> do not have checks, but now I feel this is very non-rubyish.

Do you feel you have to be rubyish?

How does writing rubyish code compare to writing good code? I mean, when
the two differ, what is the advantage of being more rubyish than good?

_____________________________________________________________________
Mathieu Bouchard -=- Montr�al QC Canada -=- http://artengine.ca/matju