On Sunday, 26 April 2015 at 01:03:12 UTC, Rikki Cattermole wrote:
I'm personally moving towards a DSL.unittest { auto myQuery = """using webdev.base.orm.query.parser.defs # allow for D class name instead of table name; # end of \"sentence\" from MyModel where key == $0 as simple # as index # but only one can be defined, two in total internal ; # end of \"sentence\" from MyModel where value contains $0 as complex # as index # but only one can be defined, two in total internal ; # end of \"sentence\" """.query; MyModel[] gotValues = myQuery.simple("test"); gotValues = myQuery.perform("complex", "another"); } Pros: - Runtime reloadability - Runtime composability - More flexible Cons: - It's a string
I get why people want to use a DSL based on the host language's constructs. The host language is built to deal with it's own constructs, so composing your queries from them allows you to easily do stuff like store query parts in variables, create functions that modify queries, use reflection on the queries, send variables and expressions from the host process directly to the query etc.
What do you gain from a string-based DSL? It doesn't allow you to do any of these things - at least not any more conveniently/efficiently/safely than you could with SQL strings - so essentially it's just a language to replace SQL.
Now, Some languages are so messed up that it's worthwhile to create a language the compiles to them(*cough* Javascript *cough*). SQL is not one of them. Even if we assume this language is better than SQL - is the difference enough to justify leanring this new language, to translate SQL errors caused by misuse of that langauge(or propagate and let the user deal with it), and deal with errors caused by bad implementation of the translation?
