Em 13-02-2011 13:04, Ernie Miller escreveu:
On Feb 13, 2011, at 3:22 AM, Prem Sichanugrist<sikand...@gmail.com> wrote:
I've been discussed the possibility of exposing ARel power with the core team
too, and found out that they thing ARel API is not mature enough to be exposed.
Maybe we should wait :)
In another hand, they don't like the extending hash for this apparent reason so
I'm pretty sure you won't see it in the future release unless you can convince
them that it's more elegant. Using that metawhere gem is you way to go :)
Prem
I'll third the recommendation for MetaWhere, though I may be biased. :)
I assume that when you mentioned extending Hash, you meant extending
Symbol. I know a number of rubyists are vehemently opposed to such
extensions, though I've never really been sure of why. I can assume
that it's because extending symbol in this way treats it as something
of an extra global namespace and that strictly from an OO purity
perspective, hanging factory methods off of symbol is considered
unsavory. That, or it has something to do with symbols not being
garbage collected and such methods encouraging/necessitating extra use
of symbols -- irrelevant in this context since hash keys are already
symbols in most cases.
Anyway, I'd contend that that from a practical perspective, "freedom
patching" in this manner makes a lot of sense. Granted, the argument
will be easier once we have module refinement, but in the meantime,
is it really that likely that your app is going to have a better use
for something like Symbol#matches than to get an ARel Matches node?
In any case, it's been working out alright for the DataMapper guys for
a while now, and I've not heard any reports of anarchy, cats sleeping
with dogs, etc...
Hi Ernie, although I like this approach or extending symbols for easying
the queries, I don't think this would be great to be included inside any
framework. This could be enabled in a per-basis application but if it
happen that you depend on another library that also needs symbols to be
extended in a conflicting way, this would lead to problems. Until Ruby
provides us some way of limitating the use of some modules per context,
I think that extending symbols that way is not the way to go with
current Ruby specification since it can lead to incompatibilities among
libraries relying on some symbol operators/methods that could be defined
in different ways.
What I'm saying is that I would be happy using your meta_where gem on my
applications, while I would not be comfortable with it being included in
ActiveRecord.
Best regards and thank you for your gem!
Rodrigo.
--
You received this message because you are subscribed to the Google Groups "Ruby on
Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
