Hash::MixIn and Python style Object#dict

ruby-talk
1

Moin.

I just did a quick implementation of Hash::MixIn (you provide .keys, ..fetch, .store and .delete and get a full-blown Hash interface) and Python style Hash access to an Object's methods.

Here's a quick sample IRB session:

irb(main):001:0> obj = "foo"
=> "foo"
irb(main):002:0> obj.dict[:reverse] = "Let's lie.".dict[:reverse]
=> #<Method: String#reverse>
irb(main):003:0> obj.reverse
=> ".eil s'teL"
irb(main):004:0> obj.dict.values_at(:reverse, :+)
=> [#<Method: "foo".reverse>, #<Method: String#+>]
irb(main):005:0> obj.dict.reject! { |key, value| key.to_s[0] == ?r }
=> #<MethodDict: :send=>#<Method: String(Kernel)#send>, ...>
irb(main):006:0> obj.dict.include?(:rindex)
=> false

The implementation of all this is available at http://flgr.0x42.net/method-dict.rb

I might include Hash::MixIn as a sample in the ruby-contract library as it would be a good case for automatically adding to the interface when a given Contract is met.

Anyway, does any part of this look useful to you?

I've heard quite a few requests for a Hash mix-in, but I'm not sure how to best make this available to the general public.

Regards,
Florian Gross

2

Florian Gross ha scritto:

Anyway, does any part of this look useful to you?

I've heard quite a few requests for a Hash mix-in, but I'm not sure how to best make this available to the general public.

I'm starting to think we could have a RubyBase package on RAA to provide lots of useful mixins (basically for fat classes i.e. IO::Readable, IO::Writable, String::MixIn, Array::MixIn, but also for new things).
What do others think?

3

+1
That would be really nice.

Are there already good mixins in "extensions" or "Facets"?

···

"gabriele renzi" <surrender_it@remove-yahoo.it> wrote

Florian Gross ha scritto:

> Anyway, does any part of this look useful to you?
>
> I've heard quite a few requests for a Hash mix-in, but I'm not sure how
> to best make this available to the general public.

I'm starting to think we could have a RubyBase package on RAA to provide
lots of useful mixins (basically for fat classes i.e. IO::Readable,
IO::Writable, String::MixIn, Array::MixIn, but also for new things).
What do others think?

4

I wouldn't call it RubyBase -- that suggests that it's part of the
base or core language, rather than extensions.

David

···

On Sat, 26 Mar 2005, gabriele renzi wrote:

Florian Gross ha scritto:

Anyway, does any part of this look useful to you?

I've heard quite a few requests for a Hash mix-in, but I'm not sure how to best make this available to the general public.

I'm starting to think we could have a RubyBase package on RAA to provide lots of useful mixins (basically for fat classes i.e. IO::Readable, IO::Writable, String::MixIn, Array::MixIn, but also for new things).
What do others think?

--
David A. Black
dblack@wobblini.net

5

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.

Incidentally I have found that letting the user define # and #= is a
bad idea because those methods are too complex (I mean those in Array and
String) and instead I make the user implement #put, #put_seq, #get,
#get_seq, for which I give extremely simple definitions.

I also use a mixin-based contract together with a mixin-based
implementation. I used to call it all ArrayMixin, HashMixin, etc., and
later changed the name because people found it was a bad name, and the
current names are worse because I confused two similar words in English
(it's a bad idea to assume my English is excellent just because I use a
lot of vocabulary: it's *not*). If I resume that project the names of the
three containers will change again (but all the rest will stay essentially
the same).

···

On Sat, 26 Mar 2005, gabriele renzi wrote:

Florian Gross ha scritto:
> Anyway, does any part of this look useful to you?
> I've heard quite a few requests for a Hash mix-in, but I'm not sure how
> to best make this available to the general public.
I'm starting to think we could have a RubyBase package on RAA to provide
lots of useful mixins (basically for fat classes i.e. IO::Readable,
IO::Writable, String::MixIn, Array::MixIn, but also for new things).
What do others think?

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

6

David A. Black ha scritto:

I'm starting to think we could have a RubyBase package on RAA to provide lots of useful mixins (basically for fat classes i.e. IO::Readable, IO::Writable, String::MixIn, Array::MixIn, but also for new things).
What do others think?

I wouldn't call it RubyBase -- that suggests that it's part of the
base or core language, rather than extensions.

Oh, the name was just the first thing coming into my head, maybe I was somewhat thinking of the Eiffel Base library which is told to be great on the side of reusability. Or maybe it was Florian talking about contracts. Anyway, I hope you agree with the underlying concept :slight_smile:

7

Mathieu Bouchard wrote:

I'm starting to think we could have a RubyBase package on RAA to provide lots of useful mixins (basically for fat classes i.e. IO::Readable, IO::Writable, String::MixIn, Array::MixIn, but also for new things).
What do others think?

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.

Certainly still an interesting project. Does it work properly on 1.8? Is documentation available online?

Incidentally I have found that letting the user define # and #= is a
bad idea because those methods are too complex (I mean those in Array and
String) and instead I make the user implement #put, #put_seq, #get,
#get_seq, for which I give extremely simple definitions.

I agreed here, but found .fetch and .store to be relatively simple. The only complex thing is that .fetch can take fallbacks in the form of Objects or blocks as well. I'm not sure how to handle that, but I guess the situation is not too bad right now.

I'm not sure what the .put_seq and .get_seq methods do though. Do they somehow replace .keys and .delete?

I also use a mixin-based contract together with a mixin-based
implementation. I used to call it all ArrayMixin, HashMixin, etc., and
later changed the name because people found it was a bad name, and the
current names are worse because I confused two similar words in English
(it's a bad idea to assume my English is excellent just because I use a
lot of vocabulary: it's *not*). If I resume that project the names of the
three containers will change again (but all the rest will stay essentially
the same).

How would the mixin-based contract look?

···

On Sat, 26 Mar 2005, gabriele renzi wrote:

8

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.

Incidentally I have found that letting the user define # and #= is a
bad idea because those methods are too complex (I mean those in Array and
String) and instead I make the user implement #put, #put_seq, #get,
#get_seq, for which I give extremely simple definitions.

Yup, I agree

I also use a mixin-based contract together with a mixin-based
implementation. I used to call it all ArrayMixin, HashMixin, etc., and
later changed the name because people found it was a bad name, and the
current names are worse because I confused two similar words in English
(it's a bad idea to assume my English is excellent just because I use a
lot of vocabulary: it's *not*). If I resume that project the names of the
three containers will change again (but all the rest will stay essentially
the same).

why those were bad name?
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 :slight_smile:

But I wonder: why both you and florian considered the need to have contracts for this mixable things?
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.

9

gabriele renzi wrote:

But I wonder: why both you and florian considered the need to have contracts for this mixable things?
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.

It's basically for letting your users check at the time they do 'include Hash::MixIn' (in this case it would be 'fulfills Hash::Contract') whether they have implemented all the prerequisites correctly. For Enumerable and so on that makes not too much as the only preconditions are providing an .each method, but I think that this could in general be quite powerful.

I've also tried to switch away from Class-based typing entirely and to instead use unit testing for defining contracts. I'm not sure of the exact implications, but it was nice to finally implement this idea that I had for so long. I've not fully explored all the possibilities though so expect to see changes and additions in the future.

10

Mathieu Bouchard wrote:
> 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.
Certainly still an interesting project. Does it work properly on 1.8?

No.

Is documentation available online?

All the doc there is, is in the tarball.

I agreed here, but found .fetch and .store to be relatively simple. The
only complex thing is that .fetch can take fallbacks in the form of
Objects or blocks as well. I'm not sure how to handle that, but I guess
the situation is not too bad right now.
I'm not sure what the .put_seq and .get_seq methods do though. Do they
somehow replace .keys and .delete?

No, in the SimpleHashP contract, it's .each_key and .remove that play
those roles, and then .each is made using .each_key, and .delete is made
using .remove.

The .put_seq and .get_seq methods are declared only in the SimpleArrayP
and SimpleStringP contracts. They implement only the a[i,n] case, whereas
.put and .get implement only the a[i] case. Basically the two seq methods
are there for efficiency. The actual full and = have more cases than
that, that get implemented in terms of those two.

How would the mixin-based contract look?

Ideally, it would be a set of around-methods that first check the
precondition, then call super, then check the postcondition; but since
Ruby only supports a small subset of Lisp method-lookup (1), it doesn't
support the aspect-oriented features (AOP) of Lisp. There are cool Ruby
packages like AspectR and DbC that do a good job of coercing Ruby into
doing it, and Ruby tends to be quite docile for that kind of thing, but I
wanted to try a different strategy.

So instead the contract is a non-class module (2) which you have to
include in a subclass of your implementation (and not in the
implementation directly, which would either require AOP features,
method-renaming, or another trick).

For example,

class MyHash; include HollowHash # (3)
  def each_key(&b)
    # blah blah blah
  end
  # further blah
end

class MyVerifiedHash < MyHash; include SimpleHashP; end

h1 = MyHash.new # unchecked (faster)
h2 = MyVerifiedHash.new # checked (safer)

That's it.

···

On Sat, 26 Mar 2005, Florian Gross wrote:

---
Notes:

(1) Namely, it's got something fairly close to Lisp's
(call-next-method) in the shape of "super", but it doesn't have
multiple-dispatch nor method-combinations and it only supports a subset of
backtracking-inheritance because of the following reason ((2)).

(2) Ruby requires the programmer to state explicitly whether a module is
instantiable or not, and those that are, are called classes, and there are
further restrictions that you know regarding what can inherit from
what. Those restrictions are not present in CommonLisp, but Ruby
programmers seem to prefer something more complicated.

(3) HollowHash is called like that because my English is bad. I actually
had ShallowHash in mind, which is 10 times more meaningful, and rhymes.
Nowadays I'm thinking about names like AbstractHash and HashShell.
Especially, the concept of kernel/shell separation as it appeared in 70's
OSes like Multics and Unix reflects pretty much the nature of the beast:
have a small set of low-level features that are have simple interfaces,
and a wrapper around them so that they become convenient to use. An
important note is that a HashShell (HollowHash) is the thing that stays
the same, while the kernel gets specialised for a given task/behaviour. In
laymen's terms, it's like you always interact with your system in the same
way using Bash or Konqueror, no matter whether you're on Linux, FreeBSD,
MacOSX, Cygwin, or QNX.

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

11

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

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?

···

On Sat, 26 Mar 2005, gabriele renzi wrote:

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

12

woops, make that:

class MyHash; include HollowHash; include SimpleStringP # (3)
  def each_key(&b)
    # blah blah blah
  end
  # further blah
end
class MyVerifiedHash < MyHash; include SimpleHashP::Contract; end

SimpleHashP is the "declarator" module, that asserts that a given module
supports a feature set. SimpleHashP::Contract is a "verifier" module.
However there is currently still no hint that a given module _wants_ an
implementation of a given feature set in the way that HollowHash wants a
SimpleHashP without providing a default implementation of it.

···

On Sat, 2 Apr 2005, Mathieu Bouchard wrote:

class MyHash; include HollowHash # (3)
  def each_key(&b)
    # blah blah blah
  end
  # further blah
end
class MyVerifiedHash < MyHash; include SimpleHashP; end

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

13

Mathieu Bouchard wrote:

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

One thing I don't quite like about duck typing is that is applied where it does not make sense to apply it.

Even the "If it quacks and walks like a duck it can be handled like a duck" is an odd one. First of all duck typing never checks the "like a duck" part. It also isn't correct to handle something that does a few things like a duck like a duck. You can handle it like something that does a few things like a duck. That's all you know.

The other area where I feel it is getting misused is calling .respond_to?() duck typing. I think that duck typing has always been about not checking, but rather just doing.

I guess views will widely differ on this subject and I'm not even sure if there is one authorative source that could clear all these different interpretations up...

14

Mathieu Bouchard ha scritto:

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

···

On Sat, 26 Mar 2005, gabriele renzi wrote:

15

Mathieu Bouchard wrote:

class MyHash; include HollowHash; include SimpleStringP # (3)
  def each_key(&b)
    # blah blah blah
  end
  # further blah
end
class MyVerifiedHash < MyHash; include SimpleHashP::Contract; end

SimpleHashP is the "declarator" module, that asserts that a given module
supports a feature set. SimpleHashP::Contract is a "verifier" module.
However there is currently still no hint that a given module _wants_ an
implementation of a given feature set in the way that HollowHash wants a
SimpleHashP without providing a default implementation of it.

This sounds a lot like something that could be done with the Contracts and implications in ruby-contract: (http://ruby-contract.rubyforge.org)

# You called this a declarator module
module Hash::MixIn
   def each_keys(&block)
     keys.each(&block)
   end

   def each(&block)
     each_keys do |key|
       block.call(key, self.fetch(key))
     end
   end

   # ... and all the other methods
end

# You called this a verifier
class Hash::Contract < Contract
   # My set again, though I wonder if .each_keys would not be a more
   # efficient primitive than .keys. I'm still not sure about the
   # difference between .remove and .delete.
   provides :fetch, :store, :keys, :delete

   # Here's a sample for a more complex provides:
   provides :fetch do
     @object.keys.each do |key|
       # Contracts are really just disguised test suites
       assert_no_exception { @object.fetch(key) }
     end
   end

   implies Hash::MixIn
end

class MyHash
   fulfills Hash::Contract
end

This contract does not yet do any detailed implementation testing, but it ought to be easy to add.

Regarding FileAsString, that could be done like this:

class Object
   adapt :to => String, :via => :read
end

Which would automatically add type adaption routes for all Objects that implement #read. If there were a method like this expecting a string:

def open(string)
   # implementation snipped...
end
signature :open, String, :result => File

And you were to call it as open(aFile) it would automatically read the filename from aFile and then pass open() that as a String. As you can see this is implicit type conversion which can be dangerous if you do it too much. Therefore I think it should really only be used in cases where the source and target are /very/ closely equivalent. One case would be two libraries providing classes for passing around Colors with incompatible interfaces.

The other things you wrote about also sounded very interesting. Perhaps we can continue talking about these things via private mail or IRC as I seem to be good at forgetting about slightly old threads on the ML...

16

Do you have any example of usage of your ruby-contract library?

Guillaume.

···

On Mon, 2005-04-04 at 09:39 +0900, Florian Groß wrote:

Mathieu Bouchard wrote:

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

One thing I don't quite like about duck typing is that is applied where
it does not make sense to apply it.

Even the "If it quacks and walks like a duck it can be handled like a
duck" is an odd one. First of all duck typing never checks the "like a
duck" part. It also isn't correct to handle something that does a few
things like a duck like a duck. You can handle it like something that
does a few things like a duck. That's all you know.

The other area where I feel it is getting misused is calling
.respond_to?() duck typing. I think that duck typing has always been
about not checking, but rather just doing.

I guess views will widely differ on this subject and I'm not even sure
if there is one authorative source that could clear all these different
interpretations up...

17

Guillaume Marcais wrote:

Do you have any example of usage of your ruby-contract library?

There's a few in the documentation (http://ruby-contract.rubyforge.org/doc/\) and another one in this thread.

I don't know exactly where this is going yet, though, so any comments are very welcome.