On Feb 13, 2011, at 3:22 AM, Prem Sichanugrist <[email protected]> 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... -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
