[RCR] Hash#getopt

ruby-talk
1

I thought AOP might be appropriate here, but I couldn't make it work:

require 'aspectr'
include AspectR

class SymAspect < Aspect
   def pre(method, object, exit_status, *args)
      puts "In the pre method"
      args.map!{ |arg| arg.to_s.downcase }
   end
end

SymAspect.new.wrap(Hash, :pre, nil, :)
h = {'foo', 1, 'bar', 2}
h['foo'] # nothing - why?

(I posted a similar question on c.l.r. via Google Groups, btw)

Regardless of whether or not this is a bug, what do you think of AOP
as an approach to this issue?

Regards,

Dan

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

···

-----Original Message-----
From: ara.t.howard@noaa.gov [mailto:ara.t.howard@noaa.gov]
Sent: Tuesday, April 25, 2006 12:21 PM
To: ruby-talk ML
Subject: Re: [RCR] Hash#getopt

On Wed, 26 Apr 2006, Berger, Daniel wrote:

> <snip>
>
> I'd rather have a class or instance level method that let me define
> this behavior globally for all hashes, or locally for
instances. That
> way I can keep the standard aref syntax, e.g. arg[:key] instead of
> using a separate method name. I wouldn't mind a way to
ignore case,
> either.
>
> h = {'foo', 1, 'BAR', 2}
> h.symbol_alias = true # or whatever
> h.ignore_key_case = true # or whatever
>
> h['foo'] # 1
> h[:foo] # 1
> h["FOO"] # 1
> h['bar'] # 2
> ... etc, etc.
>
> That being said, I'll take a Hash#getopt method over nothing. :slight_smile:

i agreed. the issue though, is that doing that sort of thing
globally for hashes requires a good bit of code to make
something like this work

   opts.values_at :key, 'key'

or

   opts_a = {:key => 42}
   opts_b = {'key' => 42.0}

   opts_a.update opts_b

by sticking to access of options only it's possible to
provide an easy way to do the normal thing in 98% of cases.
as the above two examples show though, a more general
approach involves making lots of choices about string/symbol
interaction. i actually do this in my own code but it's
slippery and not for general consumption.