rubyworks / hashery Goto Github PK

Should we wrap all the Hashery classes in a Hashery namespace module?

The reason they were not originally put in such a namespace is b/c they came either from Facets or other individual sources where they were toplevel classes.

On the whole it might be a good idea to add the namespace, but I am not sure it is worth introducing the incompatibility with previous versions at this point. If someone takes issue with it then I will put it on the todo list for a 2.0 release. Until then we'll just let the devil lie.

FYI, I'm covering this on Ruby5 tomorrow, cool library.

If anyone associated with this project felt like improving the user guide (http://github.com/rubyworks/hashery/wiki) tonight, I'm sure you'd increase adoption.

Just sayin.

Hi,

I'm trying to maintain hashery for the GNU Guix package manager, and I noticed on the upgrade to ruby 2.3.1 (or possibly 2.3.0) there was a test failure:

$ rubytest -Ilib -Itest test/
................................F.....................................................................................................................................................

Finished in 0.05111s, 3561.02 tests/s.

FAILURES


    (assertion) {}
    test/case_key_hash.rb:47
    45     test do
    46       s = KeyHash.new
 => 47       assert(s)
    48     end
    49   end
    test/case_key_hash.rb:47
    /gnu/store/jdpgw3951m4zlc4chkyy3sm6siqzp1iq-ruby-rubytest-cli-0.2.0/lib/ruby/gems/2.3.0/gems/rubytest-cli-0.2.0/lib/rubytest-cli.rb:48
    /gnu/store/jdpgw3951m4zlc4chkyy3sm6siqzp1iq-ruby-rubytest-cli-0.2.0/lib/ruby/gems/2.3.0/gems/rubytest-cli-0.2.0/lib/rubytest-cli.rb:18

I think this might stem from ae, through this testing.

irb(main):001:0> require 'ae'
=> true
irb(main):002:0> assert true
=> true
irb(main):003:0> assert {}  
AE::Assertion: (assertion) #<Proc:0x0056017f10b9a0@(irb):3>
    from (irb):3
    from /gnu/store/zg1fmaj0kl0c2hfqbyq7iahgrf2fb41a-profile/bin/irb:11:in `<main>'

I'm not sure what has changed in ruby exactly, do you have any ideas?

Thanks,
ben

When calling a key that doesn't exists, OpenCascade initializes it as an empty OpenCascade (open_cascade.rb:61)

I think it's a bad idea since you don't know if this key is supposed to be a nested hash or a value and, by the way, calling a key should not change it's value.

Why not just return "nil" if the key does not exists ?

I suggest replacing

if key?(name)
  self[name] = transform_entry(self[name])
else
  self[name] = OpenCascade.new #self.class.new
end

by

if key?(name)
  self[name] = transform_entry(self[name])
else
  nil
end

Change https://rubyworks.github.com/hashery to https://rubyworks.github.io/hashery in the "About" section

If a developer extends OpenCascade because he wants to define domain-specific methods (Like people often do with OpenStructs). And the hash that initializes this extended class has hashes nested within it...those hashes get translated into OpenCascades. That's the joy of the OpenCascade....

I'm not 100% familiar with the code but I think that's coming from leet = lambda { |h,k| h[k] = OpenCascade.new(&leet) }
Have you given thought to giving users the ability to customize that.

Here's an example

require 'hashery'

class ServerResponse < Hashery::OpenCascade
  def some_domain_specific_method
  end
end


value         = { :code => 200, :success => true, :objects => [{ :id => 1, :first_name => "John", :last_name => "smith" }, { :id => 2, :first_name => "bob", :last_name => "smith" }] }
the_response  = ServerResponse[value]

the_response.class #=> ServerResponse 
the_response.objects.first.class #=> Hashery::OpenCascade

What if I wanted each nested hash to be an instance of ServerResponse?
Just double checking that there isn't a way to do this - and was wondering if you've considered it.

Simplify overall design by basing all hash classes on a base hash class that supports a variety of callbacks to make all the other variations possible.

Almost every file in Hashery has two names, one with an underscore and one without. Eventually just have the one with the underscore and deprecate those without.

It looks like there is a problem with latest (1.3.0) gem where you specify: "require 'hashery'". Shouldn't this gem require facets gem as runtime dependency?

$ irb
irb(main):001:0> require "rubygems"
ge=> true
irb(main):002:0> gem "hashery"
=> true
irb(main):003:0> require "hashery"
LoadError: no such file to load -- facets/basicobject
 from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
`gem_original_require'
 from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
 from /usr/lib/ruby/gems/1.8/gems/hashery-1.3.0/lib/hashery/openobject.rb:1
 from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
`gem_original_require'
 from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
 from /usr/lib/ruby/gems/1.8/gems/hashery-1.3.0/lib/hashery.rb:7
 from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
`gem_original_require'
 from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
 from (irb):3

I just ran into an unfortunate interaction between hashery and rest-client.

rest-client relies on duck-typing the payload to determine whether it's already streamable or not - specifically, it checks if the payload responds to :read.

Because hashery adds a #read method to the core Hash class, rest-client concludes that a Hash is streamable (which it is, obviously, not).

I'm not sure what the right path forward is at this point, but I'm pretty sure that rest-client isn't the only library that uses the existence of a #read method to determine whether something will act like an IO or not.

(The context where I ran into this is stripe/stripe-ruby#38)

The following does not work:

require 'rubygems'
require 'hashery'

d = Dictionary.new
d[0] = 1
d[nil] = 2
d.order_by_key

=>ArgumentError: comparison of Fixnum with nil failed

Short example of the problem :

c = OpenCascade[{:length => "foo"}]
c.length
 => 1

I suggest adding something like this in OpenCascade#method_missing :

name = sym.to_s.gsub(/[=!?]$/, '')
name = name[1..-1] if name[0] == '_'
name = name.to_sym

Instead of

name = sym.to_s.gsub(/[=!?]$/, '').to_sym

To allow this syntax :

c = OpenCascade[{:length => "foo"}]
c.length
 => 1
c._length
 => "foo"

Every other Hashery class or module has a fairly explicit name. Stash on the other hand has a rather cryptic "playful" name. Should it be changed to something more literal? If so what?

Monkey patching the core Hash class is fairly invasive and might have surprising side effects for projects that require hashery.

Are the monkey patches required? Could they live on the CRUDHash class to make the functionality available where required?

Hi !

When running a 'each' on an OpenCascade, sub OpenCascades are converted to hashs if subkeys haven't been called before.

Example :

c = OpenCascade[{:a => {:aa => 1}}]
c.each do |key, nested|
  puts key
  puts nested.class
end

----

a
Hash

But :

c = OpenCascade[{:a => {:aa => 1}}]
c.a
c.each do |key, nested|
  puts key
  puts nested.class
end

----

a
OpenCascade

Sub OpenCascades seems to be actually converted to OpenCascades only when called.

Is there a way to force all nested hashs to be converted on init ?

Regards,

Gauthier.

Hiya,

Could you please explain what's the current license of this library? The reason why I'm asking is described in this issue:

https://bugzilla.redhat.com/show_bug.cgi?id=787167

README says it's Apache, COPYING says it's BSD.

Thank you!

--Marek

In the README file, where it says "I assume you have heard all the talk about proper etiquette, so I won’t bugger you with it yet again," you may want to make the words "the talk" or maybe "etiquette" into a link to somewhere with more information for those who have not heard all the talk. I, for one, have heard very little (tending to haunt Bitbucket a lot more than GitHub), and hope I'm not stepping on any toes with my pull requests tonight. Just a suggestion.

Oh, yeah . . . and was the choice of "bugger" (vulgar British slang) instead of "bug" (colloquial term for "annoy") intentional? If not, it might stand an edit.

Hi,

I cannot determine wich license applies to hashery:

• the website http://rubyworks.github.io/hashery/ says it is Copyright 2010 Thomas Sawyer, with licence Apache 2.0
• the README.rdoc file says it is Copyright 2010 Rubyworks, with license BSD-2-clause (and send to a non existing COPYING.rdoc)
• the LICENSE.txt file says it is Copyright 2009 Rubyworks, with license MIT/Expat.

Could you please clarify this?

Thank you!

my machine:

$ uname -a
Darwin portal.lan 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov  5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 i386
$ ruby -v
ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0]
$ gem -v
1.3.7
$ gem list | grep rails
rails (3.0.3)

the test:
$ rails new hashery_test
$ cd hashery_test
$ echo "gem 'facets'" >> Gemfile
$ echo "gem 'hashery'" >> Gemfile
$ bundle install
$ rails generate model Author name:string
$ rails generate model Post title:string author_id:integer
$ cat < app/models/post.rb
class Post < ActiveRecord::Base
belongs_to :author
end
END
$ rake db:migrate
$ rails console
Loading development environment (Rails 3.0.3)
ruby-1.9.2-p0 > Post.all
ArgumentError: method does not exist
from /Users/olistik/.rvm/gems/ruby-1.9.2-p0/gems/facets-2.9.0/lib/core/facets/module/redefine_method.rb:27:in redefine_method' from /Users/olistik/.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.3/lib/active_record/associations.rb:1445:inassociation_accessor_methods'
from /Users/olistik/.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.3/lib/active_record/associations.rb:1225:in belongs_to' from /Users/olistik/.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.3/lib/active_record/autosave_association.rb:137:inbelongs_to'
from /private/tmp/hashery_test/app/models/post.rb:2:in <class:Post>' from /private/tmp/hashery_test/app/models/post.rb:1:in<top (required)>'

Moreover, if you add only "hashery" to the Gemfile (and, of course, run "bundle install"), the "rails console" fails with this:
/Users/olistik/.rvm/gems/ruby-1.9.2-p0/gems/hashery-1.3.0/lib/hashery/openobject.rb:1:in require': no such file to load -- facets/basicobject (LoadError) from /Users/olistik/.rvm/gems/ruby-1.9.2-p0/gems/hashery-1.3.0/lib/hashery/openobject.rb:1:in<top (required)>'

I've put the current compatibility status here: http://railsplugins.org/plugins/605-hashery

Consider storing attributes in instance_variables instead of a single hash. This would allow it to act more like a regular class to any meta-programming code.

If a developer extends OpenCascade because he wants to define domain-specific methods (Like people often do with OpenStructs). And the hash that initializes this extended class has hashes nested within it...those hashes get translated into OpenCascades. That's the joy of the OpenCascade....

I'm not 100% familiar with the code but I think that's coming from leet = lambda { |h,k| h[k] = OpenCascade.new(&leet) }
Have you given thought to giving users the ability to customize that.

Here's an example

require 'hashery'

class ServerResponse < Hashery::OpenCascade
  def some_domain_specific_method
  end
end


value         = { :code => 200, :success => true, :objects => [{ :id => 1, :first_name => "John", :last_name => "smith" }, { :id => 2, :first_name => "bob", :last_name => "smith" }] }
the_response  = ServerResponse[value]

the_response.class #=> ServerResponse 
the_response.objects.first.class #=> Hashery::OpenCascade

What if I wanted each nested hash to be an instance of ServerResponse?
Just double checking that there isn't a way to do this - and was wondering if you've considered it.

An error and failure occur on testing with Travis Ci with Ruby 1.9.2-p290. The odd thing is that the problem does not arise on my local machine, nor does it effect any other version of Ruby either locally or on Travis CI. The tests are green. So I am left wonder if it has something to do with Bundler, b/c I am not running the tests via Bundler locally (something is wrong with my Bundler install as it can't find seem to find any gems).

I am just going to let this go for now, perhaps someone else will come across it and be able to make sense of the problem.

Here is the Travis CI output:

Using worker: ruby
worker.travis-ci.org:worker-5
$ git clone --depth=1000 --quiet git://github.com/rubyworks/hashery.git rubyworks/hashery
$ git checkout -qf bec2d88e0832a7dc10cc9f6092db4fb08beca4fc
$ rvm use 1.9.2
Using /home/vagrant/.rvm/gems/ruby-1.9.2-p290
$ export BUNDLE_GEMFILE=/home/vagrant/builds/rubyworks/hashery/Gemfile
$ export TESTCOMMAND="qed"
$ bundle install
Fetching source index for http://rubygems.org/
Installing ansi (1.4.0)
Installing ae (1.8.1)
Installing blankslate (2.1.2.4)
Installing facets (2.9.2)
Installing pom (2.1.1)
Installing detroit (0.2.0)
Using hashery (1.5.0) from source at /home/vagrant/builds/rubyworks/hashery
Installing test (0.2.1)
Installing lemon (0.9.0)
Installing qed (2.6.3)
Using bundler (1.0.21)
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.
$ bundle exec $TESTCOMMAND
Started
..............................................
E.........
F...................................................................
Finished in 0.11215 seconds.
***** ERROR *****
undefined method `z' for nil:NilClass
/home/vagrant/builds/rubyworks/hashery/qed/06_opencascade.rdoc:14
12 h = { :x => { :y => { :z => 1 } } }
13 c = OpenCascade[h]
=> 14 assert c.x.y.z == 1
15
16 As soon as you access a node it automatically becomes an OpenCascade.
***** FAIL *****
(assertion) AE::Assertion
/home/vagrant/builds/rubyworks/hashery/qed/06_opencascade.rdoc:47
45
46 assert c.x == 8
=> 47 assert c.y == 9
48
49 Finally, you can call methods ending in a !-mark to access the
9 demos, 124 steps: 1 failures, 1 errors (66/67 assertions)
Done. Build script exited with: 1