hi ara,

> ara.t.howard / noaa.gov wrote:

good food for thought. thanks ara. ...

> i use method_missing too but, in this case, you'd have to provide an extremely
> strong argument why an interface like this won't suffice:
>
[snip]
>    X.ann :x, :class   #=> String
>    X.ann :x, :default #=> 10
>    X.ann :x, :foo     #=> :bar
>
>    X.ann :x           #=> #<Annotation(X#x) {:class => String, :default => 10, :foo > :baz}>
>
>    harp:~ > ruby -W0 a.rb
>    String
>    10
>    :bar
>    {:default=>10, :class=>String, :foo=>:bar}
>
> it's simple and rather concise - adding only a char or so.

yea that's a nice implemementation esspecially for it's simplicity.
while i *tend* toward your opinion there are couple of problems. the
big one is of course my end users really likes the dot notation. and i
can understand, it certainly has a certain elegance and ease to it.
unfortunately it's a nightmare to code. btw, the notation X.ann(:x)
does work already in what I have, but another thing is this use:

  X.ann :a, :b, :c, :class => String

  X.ann.a.class   #=> String
  X.ann.b.class   #=> String
  X.ann.c.class   #=> String

Also there's a shortcut for setting the :class annotation.

  X.ann :a, :b, :c, String

I imagine that still can be worked in to your impl, but it does starts
to get a little thicker.

I should also note that it's not just annotations, I use it lots else
where too. I esspecially like using Facets' OpenCascade on YAML load
configs.

  s = %{
    a:
      b:
        c: "abc"
  }

  data = OpenCascade[ YAML.load(s) ]

  data.x.y.z  #=> "abc"

(OT. Notice BTW how I use ::[] on OpenCascade. It's a subclass of Hash.
In an earlier post I mentioned how I felt that ::new should be able to
take a hash rather than a default value --well there's why. I actually
just spent ~2 hours tracknig a bug that came down to using ::new when I
should have used []. That sucked!)

> more importanlty,
> however, the impl above actually conforms to the specification i imagine your
> annotation class requires, which is that __any__ token might be used as an
> annotation tag, for instance
>
>    ann 'x', __id__ => method('x').__id__
>
> which no method_missing approach will ever quite be able to skin.

You're right about that. There are limitations to using method_missing.
Though I don't mind so much if the limitations are *well defined* and
minimial, but the current state of affairs is too iffy.

> ps
>
>    klass.ann.x.prop
>
> becomes much longer if the arg list is in a variable, for instance, with my
> impl above it would be
>
>    args = %w( x prop )
>
>    klass.ann *args
>
> but, using a method_missing approach it becomes
>
>    args = %w( x prop )
>
>    klass.ann.send(args.first).send(args.last)
>
> this applies to many method_missing approaches: they are more consise until
> another layer of abstraction is added, like having the methods be read from a
> config file, food for thought...

Well, that could be solved with a special interface, eg.

  klass.ann.cascade_send *args

or something. But it's a good point too.

T.