OpenCascade and string keys

[Stephen Schor]

Yes - I feel dirty joining the list to ask a supportish question.

I'm a little confused OpenCasecade acts weirdly when it's initialized with a hash that uses

strings as keys.

So this example works as expected:

books = {:title => "A book's title", :author => "John Smith", :isbn => 123456}

  => {:title=>"A book's title", :author=>"John Smith", :isbn=>123456}

my_cascade = OpenCascade[books]

  => {:title=>"A book's title", :author=>"John Smith", :isbn=>123456}

my_cascade.title

  => "A book's title"

my_cascade.author

  => "John Smith"

my_cascade[:section] = "Science Fiction"

  => "Science Fiction"

my_cascade.section

  => "Science Fiction"

my_cascade

=> {:title=>"A book's title", :author=>"John Smith", :isbn=>123456, :section=>"Science Fiction"}

But things go wonky if the keys of books are strings.

books = {"title" => "A book's title", "author" => "John Smith", "isbn" => 123456}

  => {"isbn"=>123456, "author"=>"John Smith", "title"=>"A book's title"}

my_cascade = OpenCascade[books]

  => {"title"=>"A book's title", "author"=>"John Smith", "isbn"=>123456}

my_cascade.title

  => {}

my_cascade

  => {:title=>{}, "title"=>"A book's title", "author"=>"John Smith", "isbn"=>123456}

Curious what others in this situation do and why the library is implemented this way.

It seems like a common enough problem where the authors see this as a feature, not a bug.

Thanks for your time! - and thanks for the great library.

[Trans]

You expose a fair question. OpenCascade still allows for any type of hash key, even though "open access" always uses symbols. Should it only allow symbols? I chose to let it  be more flexible. But there is a way to work around in latest release. Try setting hash.covert_key(&:to_sym).

[Stephen Schor]

Hey Trans.

Thanks for the thoughtful answer.

Yeah - I think you are correct to leave it flexible.

I'm confused about " Try setting hash.convert_key(&:to_sym)."

I'm using hashery 2.0.0 and don't see convert_key() method defined - polking

around on the internet I see HashWithIndifferentAccess defines a convert_key()

method - but I doubt that's what you're talking about.

Sorry for the confusion - maybe a snippet would clarify.

Thanks,

Stephen 

[Trans]

On Mon, Jul 2, 2012 at 4:54 PM, Stephen Schor <beholdt...@gmail.com> wrote:
> Hey Trans.
>
> Thanks for the thoughtful answer.
> Yeah - I think you are correct to leave it flexible.
>
> I'm confused about " Try setting hash.convert_key(&:to_sym)."
> I'm using hashery 2.0.0 and don't see convert_key() method defined - polking
> around on the internet I see HashWithIndifferentAccess defines a
> convert_key()
> method - but I doubt that's what you're talking about.
>
> Sorry for the confusion - maybe a snippet would clarify.

Sorry, it is actually #key_proc.

It is defined in CRUDHash which OpenCascase subclasses via OpenHash.

Actually it will be interesting to see how that works, b/c thinking
about it now, I'm not certain I ensured that the key_proc will
cascade, so it might only work at the first depth. I will have to look
into that when I have some time. If you try it, let me know how it
works for you.

[Trans]

> Actually it will be interesting to see how that works, b/c thinking
> about it now, I'm not certain I ensured that the key_proc will
> cascade, so it might only work at the first depth. I will have to look
> into that when I have some time. If you try it, let me know how it
> works for you.

I just took a look at it myself. And indeed the key_proc does not get
passed on. I think it probably should, so I've made that change and it
will be in the next release. Note, the default_proc is not passed on
either, but I'm not so sure it should be. Have an opinion?

[Stephen Schor]

Hey Trans

Thanks for passing it on (https://github.com/rubyworks/hashery/commit/7252291915f8140813fc8fdda0c43256fde9c4b2)
I agree - I don't think default_proc should get passed down.

key_proc makes sense because I can imagine people wanting to access hashes arbitrarily down-the-line in a uniform way.
I can see people wanting different behavior for default_proc depending on where they are - and also being rudely
surprised when accessing an non-existent key returns something else than nil.
That said - I'd be interested if anyone disagrees.

-Stephen