On 21/03/12 21:53, Jacob Carlborg wrote:
On 2012-03-21 17:44, H. S. Teoh wrote:
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.)
"find", "map" and similar functions can be used on arrays. What's wrong
in being able to use the same syntax for accessing a database. I think
the following would be a great syntax:
Person.where(x => x.name == "John");
Where "Person" is a class connected to a database table.
Indeed, it may be possible to use a new-style delegate literal instead
of a string, for defining your DSL.
My point was that we don't need to be able to return arbitrary types
from operators. Instead, we might need some syntax sugar or library
support for getting syntax trees from expressions.
