dynamic classes and duck typing

retard re at tard.com.invalid
Wed Dec 2 03:50:23 PST 2009


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];

I agree some disciplines are hard to follow. For example ensuring 
immutability in a inherently mutable language. But TDD is something a bit 
easier - it's a lot higher level. It's easy to remember that you can't 
write any code into production code folder unless there is already code 
in test folder. You can verify with code coverage tools that you didn't 
forget to write some tests. In TDD the whole code looks different. You 
build it to be easily testable. It's provably a good way to write code - 
almost every company nowadays uses TDD and agile methods such as Scrum.



More information about the Digitalmars-d mailing list