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.

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

在 Thu, 27 Dec 2007 15:43:44 +0800，davidl <davidl@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/