[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Hash::MixIn and Python style Object#dict

Florian Gross

3/25/2005 7:12:00 PM

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

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
16 Answers

gabriele renzi

3/25/2005 7:42:00 PM

0

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?

Its Me

3/25/2005 7:49:00 PM

0

"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?

+1
That would be really nice.

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

dblack

3/25/2005 9:48:00 PM

0

gabriele renzi

3/25/2005 10:32:00 PM

0

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

Mathieu Bouchard

3/26/2005 2:23:00 AM

0

Florian Gross

3/26/2005 2:47:00 AM

0

Mathieu Bouchard wrote:

> On Sat, 26 Mar 2005, gabriele renzi 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...) 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?

gabriele renzi

3/26/2005 9:23:00 AM

0

Mathieu Bouchard ha scritto:

> MetaRuby (http://artengine.ca/matju...) 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 :)

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.

Florian Gross

3/26/2005 3:01:00 PM

0

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.

Mathieu Bouchard

4/2/2005 9:09:00 AM

0

Mathieu Bouchard

4/2/2005 10:26:00 AM

0