Short list with things to finish for D2

[aarti_pl]

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)