On Oct 26, 1:20 pm, John Firebaugh <[email protected]> wrote: > Do we have the constraint that the literalizing methods must be > defined on Sequel::Dataset itself? Is that so that adapters can add > adapter-specific overrides?
It's exactly so there can be adapter specific overrides. > If so, perhaps a data-driven approach would work. > > class Sequel::Dataset > EXPRESSION_LITERALIZERS = [ > [SQL::ComplexExpression, :complex_expression_sql], > [SQL::AliasedExpression, :aliased_expression_sql], > ... ] > > def literal_expression(expr) > EXPRESSION_LITERALIZERS.each do |class, method| > return send(method, expr) if expr === class > end > end > end > > Obviously that's not quite complete -- for example, the literalizing > methods would need to have uniform arity -- but you get the idea. To > add a new expression subclass, you add a dataset method and append to > EXPRESSION_LITERALIZERS. This is a slightly more compact form of what is already proposed. It has a similar upside with a similar downside. In your design, you could add to the EXPRESSION_LITERALIZERS array for new objects, but I think the differences in arity among the methods makes your design a bad idea. Jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sequel-talk" 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/sequel-talk?hl=en -~----------~----~----~----~------~----~------~--~---
