dynamic classes and duck typing

[Lars T. Kyllingstad]

retard wrote:
> Wed, 02 Dec 2009 03:16:58 -0800, Walter Bright wrote:
> 
>> retard wrote:
>>> The thing is, nowadays when all development should follow the
>>> principles of clean code (book), agile, and tdd/bdd, this cannot
>>> happen. You write tests first, then the production code. They say that
>>> writing tests and code takes less time than writing only the more or
>>> less buggy production code. Not writing tests is a sign of a novice
>>> programmer and they wouldn't hire you if you didn't advertise your TDD
>>> skills.
>> And therein lies the problem. You need the programmers to follow a
>> certain discipline. I don't know if you've managed programmers before,
>> but they don't always follow discipline, no matter how good they are.
>> The root problem is there's no way to *verify* that they've followed the
>> discipline, convention, procedure, whatever.
>>
>> But with mechanical checking, you can guarantee certain things. How are
>> you going to guarantee each member of your team put all the unit tests
>> in? Each time they change anything?
>>
>>> In this particular case you use a dummy test db fixture system, write
>>> tests for 'a is int' and 'b is int'. With these tests in place, the
>>> functionality provided by D's type system is only a subset of the
>>> coverage the tests provide. So D cannot offer any advantage anymore
>>> over e.g. Python.
>> Where's the advantage of:
>>
>>      assert(a is int)
>>
>> over:
>>
>>      int a;
>>
>> ? Especially if I have to follow the discipline and add them in
>> everywhere?
> 
> The case I commented on was about fetching values from a db IIRC. So the 
> connection between SQL database and D loses all type information unless 
> you build some kind of high level SQL interface which checks the types 
> (note that up-to-date checking cannot be done with dmd unless it allows 
> fetching stuff from the db on compile time or you first dump the table 
> parameters to some text file before compiling). You can't just write:
> 
>   typedef string[] row;
>   row[] a = sql_engine.execute("select * from foobar;").result;
>   int b = (int)a[0][0];
>   string c = (string)b[0][1];
> 
> and somehow expect that the first column of row 0 is an integer and the 
> next column a string. You still need to postpone the checking to runtime 
> with some validation function:
> 
>   typedef string[] row;
>   row[] a = sql_engine.execute("select * from foobar;").result;
> 
>   void runtime_assert(T)(string s) { ... }
> 
>   runtime_assert!(int)(a[0][0]);
>   int b = (int)a[0][0];
> 
>   string c = b[0][1];


std.conv.to() to the rescue! :)

   import std.conv;
   ...

   row[] a = sql_engine.execute("select * from foobar;").result;

   int b = to!int(a[0][0]);          // Throws if conversions fail
   string c = to!string(a[0][1]);

-Lars