Here's a simple test case:

require 'hashie'
class Foobar < Hashie::Dash
  property :b, default: Hash.new
end

a = Foobar.new
a.b[:bar] = 'cat'

b = Foobar.new

I'd expect b to be {}, but actually is {b: { bar: 'cat'}}

Deferred defaults (issue #34) would help, but the default objects should probably be cloned by each new instance.

Can you release a beta gem with a developer version to rubygems.org, so that the 2.0 version can be used with a simple gemfile entry?

Thanks...

initialize_reader should use self.class.new instead of Hashie::Mash.new and convert_value should use self.class instead of ::Hashie::Mash to respect subclasses of Hashie::Mash

I fixed this in this commit:

http://github.com/tcocca/hashie/commit/407e7875e82d8ec72010cf048b1b04c4a4cc017e

Thanks,
~ Tom

Mash's deep_merge is recursively invoked 2^n times, where n is the depth of the other_hash parameter. For instance,

 x = Hashie::Mash.new()
 x.a!.b!.c!.d!.e!.f!.g!.h!.i!.j!.k!.l!.m!.n!.o!.p!.q!.r!.s!.t = 0
 y = Hashie::Mash.new(x)

...will call deep_merge over a million times (2^20), taking 10-15 seconds to complete.

I've made an a O(n) fix in which deep_merge is only invoked 20 times for the above example, with sub-millisecond response. Will submit a pull request momentarily.

I'm on OS X 10.8.2 running RVM 1.16.11 with Ruby 1.9.3p194 and Hashie::Trash does not work for me at all.

This is my irb input and output, straight from the examples in the README:

1.9.3-p194 :001 > require 'hashie'
 => true 
1.9.3-p194 :002 > class Result < Hashie::Trash
1.9.3-p194 :003?>     property :id, :transform_with => lambda { |v| v.to_i }
1.9.3-p194 :004?>     property :created_at, :from => :creation_date, :with => lambda { |v| Time.parse(v) }
1.9.3-p194 :005?>   end
 => nil 
1.9.3-p194 :006 > 
1.9.3-p194 :007 >   result = Result.new(:id => '123', :creation_date => '2012-03-30 17:23:28')
 => #<Result created_at="2012-03-30 17:23:28" id="123"> 
1.9.3-p194 :008 > result.id.class         # => Fixnum
 => String 
1.9.3-p194 :009 > result.created_at.class # => Time
 => String 

When including both KeyConversion & IndifferentAccess in a Class the functions symbolize_keys and stringifiy_keys are broken.

I get an argumentError when trying to access a key named key in a hash I'm using. I've looked through the documentation, and it's looking like I'm out of luck right now. Is there any way around this that I haven't found yet?

It would be nice to provide custom errors messages so that:

ArgumentError: The property 'req_attr' is required for this Dash.

could be made into something like:

ArgumentError: The property 'req_attr" is required for the credentials hash.

Seems like it could be done as simple as:

class Credentials < Hashie::Dash
  property :req_attr, :required =>  true, :message => "is required for the credentials hash"
end

or something like that. Just an idea...

The fix for #1 caused some unfortunate side effects that breaks subclasses of Hashie::Mash that override initialize to take different parameters than Hashie::Mash. (Specifically, I encountered this issue within Redfinger's link.rb )

class Foo < Hashie::Mash
  def initialize(message)
    self[:message] = message
  end
end

f = Foo.new('hello')
f.dup

yields

ArgumentError: wrong number of arguments (2 for 1)
    from [...]/hashie-1.0.0/lib/hashie/mash.rb:97:in `initialize'
    from [...]/hashie-1.0.0/lib/hashie/mash.rb:97:in `new'
    from [...]/hashie-1.0.0/lib/hashie/mash.rb:97:in `dup'
    [snip]

because Hashie::Mash redefines dup as

alias_method :regular_dup, :dup
def dup
  self.class.new(self, self.default)
end

Mash returns false for respond_to?(:key) even when defined in Hash. Perhaps a respond_to? should be implemented. Something like this:

def self.respond_to?(method_sym, include_private = false)
if key?(method_sym)
return true
else
super
end
end

I upgraded an app from Hashie::Mash 1.2 to 2.0 and I started to notice an incompatibility when using strong_parameters (thus Rails 4).

Have a look at the following example:

settings = { foo: "1", attributes: { title: "Value" } } 

# Mash 1.2
record.attributes = settings.attributes
# it works

# Mash 2.x
record.attributes = settings.attributes
# raises ActiveModel::ForbiddenAttributes

This happens because in the 2.x version, when a key is a Hash, it is automatically converted into a Mash.

The Mash instance responds to :permit? thus it triggers the ActiveModel forbidden attribute check.

  module ForbiddenAttributesProtection
    def sanitize_for_mass_assignment(*options)
      new_attributes = options.first
      if !new_attributes.respond_to?(:permitted?) || new_attributes.permitted?
        super
      else
        raise ActiveModel::ForbiddenAttributes
      end
    end
  end

But because there is no attribute permit, then #permit? returns false and the error is raised.

Is it intentional? Any suggestion? Any chance that the implementation of Hashie::Mash#respond_to? would not return true for #attribute? unless attribute exists in the Mash table?

How can we get hashies to prettyprint better, the way pp(rubu_hash) does?

> mash = Hashie::Mash.new
> mash[:name] = 'asd'
> JSON.generate(mash)
NoMethodError: undefined method `merge' for #<JSON::Ext::Generator::State:0x4e392db8>

No worries however, for there is #to_json

Consider the following:
class A < Hashie::Dash
property :id
end
A.new # works

 class B < A
 end

 B.new # boom! 
 NoMethodError: undefined method `collect' for nil:NilClass

Fixed in my fork

Please release 0.3.2 with this fix, thanks

is there any chance you can make a 1.x that incudes #33

Yielding values to blocks would be a neat new feature for Hashie, enabling code such as mash.background { |bg| puts "Background is #{bg}" }

I have created a patch which enables this for Mash and Dash and uploaded it as a Gist: http://gist.github.com/618761

If you think it's any good, please git apply it!

Um, with the gem, how do I require the extensions . . . should the autoload bring everything in? This doesn't seem to work.

  require 'hashie'
  require 'hashie/hash_extensions'

  class IndifferentHash < Hash
    include Hashie::Extensions::IndifferentAccess
    include Hashie::Extensions::MergeInitializer
  end

Produces:

  in `<class:IndifferentHash>': uninitialized constant Hashie::Extensions (NameError)

(I'm sure this is obvious. Even if it is, it might be something to add to the readme.)

require 'hashie'

class Hash
  include Hashie::Extensions::DeepMerge
end

{ x: 1 }.deep_merge({ x: 1})

Expected results: { x: 1 }

Actual results:

TypeError: can't define singleton
    from /Users/jkeiser/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/hashie-2.0.5/lib/hashie/extensions/deep_merge.rb:14:in `block in deep_merge!'
    from /Users/jkeiser/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/hashie-2.0.5/lib/hashie/extensions/deep_merge.rb:13:in `each'
    from /Users/jkeiser/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/hashie-2.0.5/lib/hashie/extensions/deep_merge.rb:13:in `deep_merge!'
    from /Users/jkeiser/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/hashie-2.0.5/lib/hashie/extensions/deep_merge.rb:7:in `deep_merge'
    from (irb):13
    from /Users/jkeiser/.rbenv/versions/1.9.3-p125/bin/irb:12:in `<main>'

In version 2.0.5 on master branch

class Example < Hashie::Dash
  property :bang!
end

throws and error (at least in rubys 1.9.3 and 1.8.7), something about

SyntaxError: (eval):5: syntax error, unexpected tNEQ, expecting ';' or '\n'
def bang!=(value)
^
(eval):7: syntax error, unexpected keyword_end, expecting $end

My understanding is that tNEQ relates to the not equal operator ("!=").

I think that this is because Dash.property relies on class_eval "def ..." to define methods, and could be solved by using ruby's #define_method.

I will submit a pull request soon.

Not sure if this is the recommended place to leave issues as no one's left any, but I'll try anyway...

I noticed that saying mash.foo? only checks to see whether foo exists in mash. I'm using Mash to wrap query results (array of hashes) and it would be more intuitive in my case for mash.foo? to also check if foo is a truthy value like ActiveRecord does (technically, return value.present?). I wonder if you guys think this would be useful too. I realize this would break people's code if they aren't expecting this behavior, but I figure I'd ask anyway.

>> h = Hashie::Mash.new({:foo => {}}){raise 'missing method'}
=> <#Hashie::Mash foo=<#Hashie::Mash>>
>> h.foo
=> <#Hashie::Mash>
>> h.bar
RuntimeError: missing method
>> h.foo.bar
=> nil

I believe that last line should throw an exception.

hi, love the gem, but i found a small problem:

steps to reproduce:

irb(main):003:0> require 'hashie'
=> true
irb(main):004:0> class Record < Hashie::Mash
irb(main):005:1> end
=> nil
irb(main):006:0> r = Record.new
=> <#Record>
irb(main):007:0> r.child = Record.new
=> <#Record>
irb(main):008:0> r
=> <#Record child=<#Hashie::Mash>>

expected behavior: r.child would not get transformed back into a Hashie::Mash object.

Hi,

Here is an example :

h = Hashie::Mash.new({:size => 10, :count => 5})
# => {"count"=>5, "size"=>10}
h.size
# => 2
h.count
# => 2
h[:size]
# => 10
h[:count]
# => 5

Is there a generic way to use the method way without the risk of hitting "native" Ruby methods ?

PS : Thank you very much for making and maintaining Hashie. I love it and appreciate your effort.

In version 2.0.5, master branch

to_hash should be symmetric with the recursive construction of Mash objects.

> Hashie::Mash.new({:key => [{}]})
=> #<Hashie::Mash key=[#<Hashie::Mash>]>

>_.to_hash
=> {"key"=>[#<Hashie::Mash>]}

I think that calling to_hash should recurse into arrays, so that the result for the example above would be
=> {"key"=>[{}]}

alternatively, there could be a #deep_to_hash method or something that recurses appropriately.

Using hashie 2.0.3

1.9.3p392 :001 > require 'hashie'
true
1.9.3p392 :002 > h = Hashie::Mash.new
{}
1.9.3p392 :003 > h.fetch(:a, nil)
KeyError: key not found: :a

Expected: nil (consistent with what ruby Hash does)
Got: KeyError

Suggested solution: either use *args and count number of arguments or use some singleton object for NO_VALUE constant case instead of nil.
Also possible: transform first argument and use super a-la HashExtensions::IndifferentAccess.

Workaround for current version: use block defaults

With Ruby's standart Hash you can use fetch method to fetch key or get a KeyError exception if the key does not exist.

Like this:

hash = { :one => 1 }
hash.fetch(:one)  # => 1
hash.fetch(:two)  # => KeyError: key not found: :two

However, you can not do this with Mash:

require 'hashie'
mash = Hashie::Mash.new(:one => 1)
mash.fetch(:one)  # => KeyError: key not found: :one
mash.fetch(:two)  # => KeyError: key not found: :two
mash.fetch("one") # => 1

Irb example:

irb(main):001:0> require 'hashie'
=> true
irb(main):002:0> mash = Hashie::Mash.new(:one => 1)
=> #<Hashie::Mash one=1>
irb(main):003:0> mash.fetch(:one)
KeyError: key not found: :one
        from ...
irb(main):004:0> mash.fetch(:two)
KeyError: key not found: :two
        from ...
irb(main):005:0> mash.fetch("one")
=> 1

Docs here: http://www.ruby-doc.org/core-1.9.3/Hash.html#method-i-fetch

Can you plaese fix the behavior of fetch method?

Hashie 2.0.3

1.9.3p392 :001 > require 'hashie'
true
1.9.3p392 :002 > h = Hashie::Mash.new
{}
1.9.3p392 :003 > h[:key] = nil
nil
1.9.3p392 :004 > h.fetch(:key, 123)
123

Expected: nil (consistent with what ruby Hash does)
Got: 123

fetch should check, whether key is present in the Mash.

falsy values are values like any other.

I noticed Dash code is dangerously unoptimized and that tests are lacking. Fixed in my fork—full explanation in related commit.

Because this changes the return values of properties and defaults class methods, it might not be a good idea for a patch release, but might be a good fit for 0.4.0

I have two gems that require different versions of hashie. If I change the dependency to the current version, will these gems break?

Essentially, are new versions of hashie backward compatible with old one?

Bundler could not find compatible versions for gem "hashie":
In Gemfile:

congress (>= 0) ruby depends on
  hashie (~> 1.0.0) ruby

transparency_data (~> 0.0.4) ruby depends on
  hashie (0.2.0)

(h[:key] ||= []) << value
doesn't work - it loses the first value - because, unlike Hash, Hashies return the value passed in but don't store that value if it's an array or hash.

It would work if Hashies returned the converted value. I don't know if that would break anything else.

This is a nice compact idiom and it's a shame we can't use it - and it's a bit subtle to debug.

I just stumbled upon hashie, and I think this Rash class I wrote a while ago would fit very nicely: https://github.com/epitron/epitools/blob/master/lib/epitools/rash.rb

If you use a Regexp as a key, whenever you lookup a value in the Rash, it will see if your key matches the regular expression(s). (A bit like how routes work.)

(There's a spec too: https://github.com/epitron/epitools/blob/master/spec/rash_spec.rb )

Feel free to include if it you think it would be useful!

In hashie 1.2, when updating my app to ruby 1.9.2, hashie is no longer symbolizing keys correctly. It seems pretty unlikely that there would be such a big difference in behavior but I can't find any other explanation, and some commits between head and 1.2 seem to be regarding this. (i'm not very familiar with the hashie code, it's used by a library i'm using)

Is there a workaround for 1.2 to solve this problem?

Perhaps the difference in behavior should be documented in the readme?

Thanks!

Seems you removed the argument in the to_hash method, which cause other Gems to break (e.g. the Omniauth, when trying Facebook connect)

Hey,

I was wanting the ability to pass a method, collection, or lambda/proc to a hashie property. What it should do is limit the options that the property can take.

property :gender, options: [:male, :female, :meat_popsicle]
property :age, options: age_range
property :hair_color, options: ->{ hex_color? }

def age_range
18...25
#more logic, I guess
end

Or something similar.

I noticed the Coercion extension recently added to hashie, and think it's a great idea. However, I've had some problems getting it to play nice with Hashie::Mash. For example, given these class definitions:

class User < Hashie::Mash
end

class Tweet < Hashie::Mash
  include Hashie::Extensions::Coercion
  coerce_key :user, User
end

If I create a new Tweet, passing a :user hash, coercion is not done; I end up with an embedded Tweet instance:

> tweet = Tweet.new(:msg => 'Hello', :user => {:email => '[email protected]'})
 => #<Tweet msg="Hello" user=#<Tweet email="[email protected]">> 

Setting user via attribute reference (via Hashie::Mash#method_missing) does the same:

> tweet.user = {:email => '[email protected]'}
 => {:email=>"[email protected]"} 
> tweet
 => #<Tweet msg="Hello" user=#<Tweet email="[email protected]">>

As does string-indexing:

> tweet['user'] = {:email => '[email protected]'}
 => {:email=>"[email protected]"}
> tweet
 => #<Tweet msg="Hello" user=#<Tweet email="[email protected]">>

However, with symbolic indexing, coercion does work as expected, and the embedded user object becomes a User instance:

> tweet[:user] = {:email => '[email protected]'}
 => {:email=>"[email protected]"} 
> tweet
 => #<Tweet msg="Hello" user=#<User email="[email protected]">>

I think it would be awesome if coercion worked with the other key-indexing methods (attribute, string, and initialize-based attributes) in addition to symbolic-key indexing, but I do wonder if there's a technical or compatibility reason this is not already the case. Is there?

If not, would there be any objection to me implementing this and submitting a pull request?

I added a new extension in my branch here: http://github.com/tcocca/hashie/commit/fe03140b7506d45b3ebe151218e124a00c272edf

Its called a Rash, which is just a rubyified Mash. It converts all the hash keys from camelcased keys to underscored keys so it is nicer to work with. Let me know if this is something you would be interested in. Also, if it needs any cleanup please let me know.

Thanks,
~ Tom

Looking for something like this:
http://www.ruby-doc.org/core-1.9.3/Hash.html#method-i-merge

@mbleigh and @intridea, there are some older issues and pulls that haven't gotten any responses. I'd be happy to help follow up and possibly close some of them if that'd be helpful.

$ irb -r rubygems -r hashie
irb(main):001:0> class X < Hashie::Mash
irb(main):002:1> def initialize(*options)
irb(main):003:2>   puts "x"
irb(main):004:2> end
irb(main):005:1> end
=> nil
irb(main):006:0> x=X.new
x
x
=> <#X>
irb(main):007:0> x
x
=> <#X>
irb(main):008:0> x
x
=> <#X>

Happens with version 0.3.1 and above.

I'm using Hashie::Mash (v1.2.0) to create a couple custom inheritable "results" classes which are used like hashes with extra logic attached to it.

I came across an issue with the #replace method. Namely it doesn't act as it does for a normal Hash. Old keys seems to be removed, and new ones added, but all values are nil, and the #key_name? helper methods all return false.

I couldn't find any issues reported about the #replace method, and it doesn't seem defined within Hashie. I don't have time right now to properly familiarize myself with the codebase and submit a pull request. I'll have time in the next few days though if that's preferred :)

For the time being, here's the quick work-around I threw into my own base-class:

def replace(hash)
  (keys - hash.keys).each { |key| delete(key) }
  hash.each { |key, value| self[key] = value }
end

Hi,

Using Hashie 1.0.0

I appologize if this is the worse issue or question ever ahead of time. But has anyone else reported an issue with Hashie incorrectly merging nested records to json?
I have an application where I've been using hashie to make a very large object consisting of nested arrays and other hashes. Everything looks fine, but when I send the hash over the wire, the params on the other side are incorrectly placed.

The hash is something like the following
{ :company => {:some_attribute => "foo", :some_nested_array => [{:x => 1, :y => 2}, {:x => 3, :z => 4}]}}

The params on the server side will have :some_nested_array => [{:x => 1, :y => 2, :z => 4}, {:x => 3}]

Was this a known issue, and possibly fixed? Or has anyone else come across this?

Hashie 2.0.0 is giving this warning:

hashie-2.0.0/lib/hashie/mash.rb:80: warning: redefining `object_id' may cause serious problems

The protective #included in HashExtensions seems like overkill to me. This code:

    def self.included(base)
      # Don't tread on existing extensions of Hash by
      # adding methods that are likely to exist.
      %w(stringify_keys stringify_keys!).each do |hashie_method|
        base.send :alias_method, hashie_method, "hashie_#{hashie_method}" unless base.instance_methods.include?(hashie_method)
      end
    end

It basically means that Hashie's extensions always take a backseat to any other library's extensions. What if I want Hashie's to take precedence? If you left the above code out I could decide which extensions take precedence by the order in which I load them.

This looks really ugly:

c = Hashie::Clash.new.where!.abc('def').ghi(123)._end!.order(:created_at)

I realized that you could do this:

c = Hashie::Clash.new.instance_eval do
  where!.instance_eval do
    abc 'def'
    ghi 123
  end
  order :created_at
end

Would it be possible to make it so you can write code like this?

c = Hashie::Clash.new do
  where do
    abc 'def'
    ghi 123
  end
  order :created_at
end

Also, would it be possible to put Mash and Clash together in something separate, with this functionality?

This one is kind of weird. I'm not sure what the issue is, other than when I try and access a method on a Mash, it responds strangely.

For example:

a = order.billing_address
=> #<Hashie::Mash address1="1234 Roslyn Road" address2="" city="Some Harbor" company="" country="United States" country_code="US" first_name="Joe" last_name="Public" latitude="42.14955" longitude="-86.349679" name="Joe Public" phone="555-555-1212" province="Michigan" province_code="MI" zip="49000"> 

a.city
=> "Some Harbor" 

a.zip
=> [[["address1", "1234 Roslyn Road"]], [["address2", ""]], [["city", "Some Harbor"]], [["company", ""]], [["country", "United States"]], [["first_name", "Joe"]], [["last_name", "Public"]], [["latitude", "42.14955"]], [["longitude", "-86.349679"]], [["phone", "555-555-1212"]], [["province", "Michigan"]], [["zip", "49000"]], [["name", "Joe Public"]], [["country_code", "US"]], [["province_code", "MI"]]]

As you can see, for some reason the zip attribute returns an array or everything in the Mash. Is this just a naming thing? Any ideas about what might be causing this?

Thanks for your help.

Hi, could you help to explain why this spec is failing? I almost broke my mind, but cannot find the cause.

diff --git a/spec/hashie/dash_spec.rb b/spec/hashie/dash_spec.rb
index 2de5490..b2e37cd 100644
--- a/spec/hashie/dash_spec.rb
+++ b/spec/hashie/dash_spec.rb
@@ -27,6 +27,11 @@ describe DashTest do
     subject.email = '[email protected]'
     subject.inspect.should == '<#DashTest count=0 email="[email protected]" first_name="Bob">'
   end
+
+  it 'update properties with regular Hash#update method' do
+    subject.update(:first_name => 'Bob', :email => '[email protected]')
+    subject.inspect.should == '<#DashTest count=0 email="[email protected]" first_name="Bob">'
+  end

   its(:count) { should be_zero }

on ruby 1.9.3 and latest Hashie I get this message :
hashie/mash.rb:80: warning: redefining `object_id' may cause serious problems

This happend in irb or with rubymine

Seems to work but affect debugging in Rubymine

If i'm only using mash, suppressing this method seems not to affect the program;

So I need a little help

my code is

# encoding: utf-8

require 'hashie/mash'

class AppConfig

  class ConfigError < StandardError;
  end

  attr_reader :config
  # load the configuration file
  def initialize(env)
    @config = Hashie::Mash.new YAML::load_file(File.join(APP_ROOT, 'config.yml'))[env]
    unless @config
      App.log("Environment '#{env}' not found in config file. Aborting!", Logger::FATAL)
      raise ConfigError
    end
  end

end

My request is similar to #17. Hashie::Mash, out of the box, doesn't provide a way to distinguish between a fat-fingered/typo'd key and a key that exists but is set to nil. I saw @mbleigh's comment on #17 saying that Hashie::Mash is meant to work like a hash, and since that's how a hash works, that's how a Hashie::Mash works. I get that. The suggested he suggested in that thread works OK for flat hash but falls apart once you start working with nested hashes:

1.9.3p194 :001 > require 'hashie/mash'
 => true 
1.9.3p194 :002 > h = Hashie::Mash.new('a' => { 'b' => 3 }) { raise NoMethodError }
 => #<Hashie::Mash a=#<Hashie::Mash b=3>> 
1.9.3p194 :003 > h.a
 => #<Hashie::Mash b=3> 
1.9.3p194 :004 > h.a.c
 => nil 
1.9.3p194 :005 > h.b
NoMethodError: NoMethodError
    from (irb):2:in `block in irb_binding'
    from /Users/myron/code/interpol/bundle/ruby/1.9.1/gems/hashie-1.2.0/lib/hashie/mash.rb:173:in `yield'
    from /Users/myron/code/interpol/bundle/ruby/1.9.1/gems/hashie-1.2.0/lib/hashie/mash.rb:173:in `default'
    from /Users/myron/code/interpol/bundle/ruby/1.9.1/gems/hashie-1.2.0/lib/hashie/mash.rb:173:in `method_missing'
    from (irb):5
    from /Users/myron/.rvm/rubies/ruby-1.9.3-p194/bin/irb:16:in `<main>'

I came up with a version that does work, but it feels like a lot of code for something that should be simpler:

require 'hashie/mash'

module Interpol
  module DynamicStruct
    DEFAULT_PROC = lambda do |hash, key|
      raise NoMethodError, "undefined method `#{key}' for #{hash.inspect}"
    end 

    def self.new(source)
      hash = Hashie::Mash.new(source)
      recursively_freeze(hash)
      hash
    end 

    def self.recursively_freeze(object)
      case object
        when Array
          object.each { |obj| recursively_freeze(obj) }
        when Hash
          object.default_proc = DEFAULT_PROC
          recursively_freeze(object.values)
      end 
    end 
  end 
end

On top of that, it took me several hours to come up with this working version; I had several previous attempts that did things like subclass Hashie::Mash but I kept getting errors on instantiation that I couldn't work around. This version I've come up with also suffers from a potential perf issue: it has to walk the entire nested hash tree to ensure every level gets this behavior.

Ideally, I'd love if Hashie supported one of these two things out of the box:

# A subclass of `Hashie::Mash` that raises errors on undefined keys.
mash = Hashie::ConservatieMash.new("a" => { "b" => 3 }) # or some better name

# ...or, have `Hashie::Mash` propogate the default proc to all levels of the hash (including to hashes w/in nested arrays)
mash = Hashie::Mash.new("a" => { "b" => 3 }) { raise NoMethodError }

Example:

class NewsfeedItem < ::Hashie::Trash
  property :comments_count, :from => :comments, :transform_with => lambda {|v| v['count'] }
end

NewsfeedItem.new(:comments => {"count" => 1}).comments_count # => got: {"count" => 1}, expected: 1