• davidl <davidl 126.com> Dec 26 2007
• davidl <davidl 126.com> Dec 26 2007

davidl <davidl 126.com> writes:

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/

davidl <davidl 126.com> writes:

在 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/