OptionalHash and a bunch of Rubocop cleanup

[nz]

OptionalHash enhances Hash by returning Option where appropriate.

[h3h]

Hmmm. These semantics seem slightly off to me. I think you want to retain nil as a valid value at a specific hash key.

I think this should check the key existence directly and go for None() in the case of a missing key, no?

Something like…

Suggested change

	obj = super(key)
	obj.nil? ? None() : Some(obj)
	key?(key) ? Some(super[key]) : None()

The semantics are weird if it presumes to understand the value, at least according to my understanding…

>> h = {}
=> {}

>> h[:a] = 1
=> 1

>> h[:b] = nil
=> nil

>> h
=> {:a=>1, :b=>nil}

>> h[:b] # this is intentional and therefore a valid value
=> nil

>> h[:c] # this is where we want None() to play a part
=> nil

[nz]

You know, that's a good point. Adding to the tests!

[nz]

This implementation is probably a disaster, I am interested in something properly recursive based on key checks. Although dig semantics will certainly blur the difference between nil as value and nil as non-existent value. So I'm torn.

[h3h]

I think that probably requires defining our expectations for dig's semantics.

I would say: “traverse this nested set of keys and return the value at the final nested key, if it exists.”

In which case, the Optional treatment could break down to something like:

• Until the given chain (ordered list) of keys are exhausted:
  • Try to access the current nested hash at the next nested key
    • If the key exists, and the value at the key is a Hash, and there are further keys in the chain, recurse on the value
    • If the key exists and there are no more keys in the chain, return Some(value)
    • Else return None()