Mathieu Bouchard ha scritto:
> 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.

I see.

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

I don't know if it would be useful, but I think it could be /possible/ 
to have a data structure wich does not carry all the keys in memory. I 
can be wrong anyway.

<snip>


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

I see your point
<snip>
>>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?

I like the way ruby works and I want it to be consistent.
This does not mean something different is inherently bad, just, well, 
different. If code is bad written, I'd say it's unrubyish, too.

I won't define