[Nitro] Preparing nitro 0.50
transfire at gmail.com
Fri Aug 10 21:16:35 EDT 2007
On Aug 10, 5:47 pm, James Britt <james.br... at gmail.com> wrote:
> George Moschovitis wrote:
> > I'm surprised you didn't leave property as an alias of attr_accessor.
> > I think that's a reasonable thing to do, since it's a simple thing,
> > and will help backward compatibility (and remains available should you
> > ever reconsider the attr_accessor decsision ;)
> > well, I will add this again ;-)
> But please add deprecation warnings for it.
Well, not unless it in fact will be deprecated. I don;t necessarily
see anything wrong with supporting both. At the very least, it can
always be an optional require.
> What I like about Og is that you can code more or less plain Ruby and,
> with a few extra moves, get automagic persistence.
I agree. That is a benefit. But it's "not quite" b/c you still have to
specify the persistence class. Eg.
attr_accessor :x, String
That "String" throws it off, so then is it really any better than
I sometimes feel a little uncomfortable about the override of the attr
methods. I guess one of the reasons is that Ara has his own lib that
overrides them for defaults, like so:
attr_accessor :x => "foo"
Which seems pretty useful too. An you can generally infer the class
from a default, but unfortunately not always. Obviously Ara's override
scheme is more limited than annotations. We can do the same with:
attr_accessor :x, :default => "foo"
but, it's just an annotation and doesn't actually do what Ara's does
(ie. prime @x with "foo"). Rather it provides Og with some persistence
metadata. But what if we wanted both?
Stuff like this has made me concerned about annotation conflicts.
While it seems like annotations should have the potential to become a
powerful general purpose tool, the potential of such conflicts may be
a seriously limiting flaw. Can it be overcome? --some sort of
annotations namespaces perhaps? Or am I just worrying over a mole
More information about the Nitro-general