On Wed, Mar 21, 2012 at 03:29:21PM +0100, Brian Palmer wrote: > On Wednesday, 21 March 2012 at 11:05:41 UTC, Don Clugston wrote: > > >I don't think this is EVER what you really want. > >I believe that if you think you want this feature, 100% of the > >time, what you really want is a syntax tree of the entire > >expression. That is, either you want ">" to be a comparison, and > >"+" to be an addition, OR you want a syntax tree. > > Well yes, the whole point is to build up a syntax tree that can be > manipulated before being outputted as a raw sql string. The operator > overloading is a convenient way to do that, that has turned out to > be intuitive and easy for developers to use in many other DSLs. To > say that's not EVER what you really want seems a bit silly, > considering all the libraries in other languages that utilize this > technique. > > That said, if this isn't the D way, it's not the D way, I'm > certainly not going to try and shoe-horn it in based on undefined > behavior or something.
The "D way" is to use strings for DSELs which get evaluated at compile-time, or a custom set of methods that you can build expressions out of. Operator overloading really should be limited to arithmetic types (for numerical classes) and built-in operations like array lookups and stuff. Trying to shoehorn language-level operators to do something they weren't intended to do only leads to problems. (C++'s overloading of << and >> for I/O is a very bad design decision IMO.) T -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- Michael Beibl
