Don pisze:
Additionally in my framework you can pass around parts of SQL e.g. :
WhereExpression exp = Where(More(visitcards.id, 100));
You basically *CAN NOT* do it when just using strings.
Of course you can define a where clause using strings.
(I'm not sure when you'd want to, though. I suspect that the fact that
you can do it in your framework, is an implementation detail rather than
a design goal. It's easy to think of uses for run-time generated naked
WHERE clauses, but much harder for compile-time ones).
Not exactly. At least it was not the case last time we talked about it:
*I will give here only NG post numbers*
79272 Domain Specific Languages in D; was: C++, D: Dinosaurs?
81026 Operator overloading
81078
81393
And you finally agreed with me that it is not possible. So I take it
proven :-)
81424
Possibility to split whole SQL statement into parts is useful. You can
mix & match these parts together as you want. It is similar as you want
to split you big chunk of code into smaller parts. You can for example
make separate expressions objects and then put them one by one into Where().
`AND` is not operator overloading in the traditional sense. This is
something else. You're proposing a whole new infix notation, and it's
difficult to evaluate it without knowing how it would work.
Well, with Andrei's proposition it is obvious for me that it should be
generalized. I stated it already in: 81392 (almost one year ago)
I will cite part of this e-mail:
*<citation>*
Exactly. My first thoughts was to allow defining infix
keywords/operators in a similar way as today we can define prefix operators:
myFunc a b
or just:
myFunc(a, b);
Why? Because they are use cases where infix notation is much, much more
natural than prefix notation.
So we still need:
1. a myFunc b - infix operator
2. a b myFunc - postfix operator
*</citation>*
After reading my old e-mail it seems that it can be further generalized:
prefix(tuple_args)
(tuple_args)postfix
(tuple_args)infix(tuple_args)
Ok. Just a thought :-)
Some more about more precise definition of this feature (proposals, to
think about it):
1. I don't agree that it is something different than traditional
operator overloading. It is just generalization.
2. After including Andrei's proposal the biggest part of this feature
will be already in language.
3. The only think to define is just how the caller side should like:
a. Always demand `` when using operator overloading; (Pros: no abuse of
operators - you always know when operator overloading is involved; Cons:
doesn't look so good, especially in cases where you would expect plain
symbols)
b. Don't demand `` in case of some standard operators like <>+-*/ etc.
In other cases demand ``(Pros: Looks better; Cons: you will not always
know that operator overloading is involved)
c. Demand `` always when there is standard operator defined or operator
is not symbol, but identifier.
d. Don't allow redefinition of same operator
Above concepts must be discussed, but it seems that there is not enough
courage in NG to change current situation.
Well it's strange that the feature is called 'operator overloading' -
it's quite obvious that it's about defining some special functions. And
IMHO some other languages got it right.
I don't understand why `Like` is an operator, but `Where` is not. You
haven't addressed operator precedence.
'Like' against 'Where': it's definitely implementation detail of my
framework. I don't think we should discuss it.
And I still don't think it looks terribly good for SQL. With:
id `>` 100
users would always be thinking, "why can't I just write id > 100 ? That
` is so annoying!"
Please believe me: it's 3000 times better than current situation.
Additionally using such framework is pure pleasure and you want miss
string SQLs even in current, bad situation :-)
Best Regards
Marcin Kuszczak
(aarti_pl)
