in reply to Converting Hashes to Objects

Any code references present in the hash will become methods.
This makes it sound like you can add methods after creating the hash. (Or, if keys are locked, that you can turn an existing key into a method), but from reading the code it looks like only subref present at creation are called directly.

My original question was about whether the -meth option made it impossible to have a subref as a value, the answer would be it's impossible to have both methods and subref values at creation. Maybe the methods should be removed from the hashs' keys though, otherwise if you iterate over the hash with each it would be impossible to tell methods and subref values appart. Also if you have a method $hash->meth(), this mean you'd be able to set $hash->{meth} (to either a plain value or a subref) without any impact on the method call.

Replies are listed 'Best First'.
Re^2: Converting Hashes to Objects (updated)
by haukex (Bishop) on May 19, 2020 at 12:18 UTC

    Thank you for the feedback, that's an excellent point! I'll clarify the documentation. And I agree it does make sense to remove the hash entries that were turned into methods like you suggested. I'll have to think a bit more about whether it makes sense to also keep the method name in the "allowed keys" of the hash.

    Update 2020-05-23: I thought about this some more, and I've decided to delete the hash entry and remove the key from the "allowed keys", unless that key is also specified in @allowed_keys. This allows the user to keep the typo prevention by default, but also optionally keep the key in the hash, for example in case they want to write a custom getter/setter. I just released v0.08 with this change, thank you!