Trans
7/16/2006 7:03:00 PM
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.