Proposal:better COM support and DB support?

[davidl]

在 Thu, 27 Dec 2007 15:43:44 +0800，davidl <davidl at 126.com> 写道:

> The idea is compile time convert DotExp to a String.
>
> consider:
> class COMBase
> {
>     Variant opDotExp(string field)
>    {
>       //do shit with COM
>    }
> }
>
> COMBase mycominst;
> mycominst.kk(); <-- this would actually result code  
> mycominst.opDotExp("kk()") by the compiler
>
> I don't quite like the syntax of  
> mycominst.Call_My_COM_Method("Method_Name", ...)
>
> and consider:
>
> abstract class FieldClass
> {
>     Variant k;
>     int opImplicitCastTo(){ throw new Exception("this is not an int  
> field");};
>     float opImplicitCastTo(){throw new Exception("this is not a float  
> field");};
>     double opImplicitCastTo(){throw new Exception("this is not a double  
> field");};
>     string opImplicitCastTo(){throw new Exception("this is not a string  
> field");};
> }
>
> class MyIntField:FieldClass
> {
>     int opImplicitCastTo(){ return k.toInt;}
>     this (Variant t){k = t;}
> }
>
> class MyTable
> {
>     FieldClass opDotExp(string field)  // compiler only comes to this  
> when compiler fails to match any DotExp
>     {
>         Variant t;
>         // get field from database and put it to variant t.
>         static if (field == "MyIntField")
>           return new MyIntField(t);
>         else static if (field == "MyFloatField")
>           return new MyFloatField(t);   // a similar helper class like  
> MyIntField would be required
>         else static if (field == "MyDoubleField")
>           return new MyDoubleField(t);  // a similar helper class like  
> MyIntField would be required
>         else
>           static assert(0);   // this operator should end with static  
> assert(0);
>     }
> }
>
>
> MyTable table;
> table.MyIntField = 3;    // this would result actually a MyIntField  
> object and if programmer implement the opAssign of MyIntField class,  
> then it would be possible for programmer to handle database in a very  
> nice language integrated syntax.
>
> Yes, string mixin can handle it very well. But I still like the LINQ  
> syntax.
>
> So compile-time DotExp to a string would bring us two things very nice.
> 1.better COM syntax.
> 2.LINQ syntax available.
>

Oh, I'm confused by ADO and LINQ.
the LINQ object like field is actually a class binding. and LINQ select  
blah syntax is evil.
I'm not particularly enjoy it.

My proposal only do good for not-binded COM object. People can do quick  
hack in binded syntax.

-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/