Don Wrote: > Chad J wrote: > > Don wrote: > >> I quite agree. What we can do already is: > >> > >> auto statement = db.execute!(`select $a from table where $b > 100 && $c > >> Like "A*"`)(visitcars.name,visitcars.id, visitcars.surname); > >> > >> which I personally like much better than the proposed goal: > >> > >>>> It would be so much better to write: > >>>> auto statement = Select(visitcars.name).Where((visitcards.id `>` 100) > >>>> `AND` (visitcards.surname `Like` "A*")); > >> (Replace $a with your preferred method for defining placeholder variables). > >> > >> And the question then is, can we improve the existing solution? And if > >> so, how? I just don't think the solution involves overloading operators. > >> I think this a great example of why we *don't* want arbitrary operator > >> overloading: there's no point overloading && and > if you can't make > >> 'from', 'where', and 'like' to all be infix operators, as well! > > > > This sounds like a job for better mixin syntax. > > > > So let "template#(args)" be equivalent to "mixin(template!(args))". > > > > Then you can do > > > > auto statement = db.execute#(`select $visitcars.name from table where > > $visitcars.id > 100 && $visitcars.surname Like "A*"`); > > Yeah, something like that. Or it could mixin automatically. eg if > macro foo(args...) > foo(args) meant mixin(foo(args)). > > then the syntax would be: > db.execute(`select $visitcars.name from table where $visitcars.id > 100 > && $visitcars.surname Like "A*"`); > > which has advantages and disadvantages. So there's quite a bit of > flexibility. A lot of potential for brainstorming!
a few points I want to add: 1) I though that :name was in some version of the SQL standard or a know extension so if we use this in APIs for D we should use the standard notation (can anyone verify this?) 2) I don't want to mix this discussion with infix functions and operator overloading. I'm not sure I want to limit these and perhaps there are other legitimate uses for general purpose infix functions. In this post I just pointed out that SQL is *not* a legitimate use case for that. 3) the Nemerle macros for SQL allow for: db.execute(`select $visitcars.name from table where $visitcars.id > 100 && $visitcars.surname Like "A*"`); the $ in Nemerle is used for controled breaking of hygene. Their Macro translates such a query into a sql string with :names and calls for the bind API to connect those with the given variables in a type-safe way. IIRC, they use the db connection object to conncet to the DB at compile-time and check the syntax and also existence of the objects (tables, columns, etc) in the DB schema.