Andrei Alexandrescu:
Youtube: http://youtube.com/watch?v=ph_uU7_QGY0
It's an interesting talk. Maybe all talks of this conference were
interesting.
Some notes on the slides.
- - - - - - - - - - - -
Slide 12:
A class is an item with a strict boundary. e.g.: Arrays will be
dupped at these borders.<
I think this kind of privacy for reference data is a common need.
I think enforcing this is not a job of static analysis tools, it
looks like a job for the type system. An annotation should
suffice (in theory this annotation should allow the access of the
array from outside, so it should be forbidden by default for
private fields. Now this can't be done, so an annotation needs to
do the opposite). Maybe this needs some discussion in the main D
newsgroup.
- - - - - - - - - - - -
Slide 12:
We do not use Ddoc, because most important information about
functions are not included.
- In- / Out-Constrains
- Exceptional Cases aka Throws<
How to annotate throws in ddoct? Do they need to be generated
automatically?
Regarding pre/post conditions, maybe a ddoc macro or switch can
be used to make them appear in the ddoc output on request.
- - - - - - - - - - - -
Slide 12:
Next to classes also model package dependency
- no cyclic dependencies anymore<
Maybe it's possisible to add some way (like a standard
annotation) to enforce the absence of cyclic dependencies in a
section of a project (like inside a package).
- - - - - - - - - - - -
Slide 14:
- Private static functions which could be tested inplace are
tested using D-unittest-Blocks (Unit =:= Function)
- Other tests require setups, teardowns, names (Testdox
http://agiledox.sourceforge.net/). Need to be filtered, selected.
For them using Dunit. (Unit =:= Class / Struct)<
I think the built-in unit test system should be improved, so in
_most_ cases there's no need to use a second unittest system.
Bye,
bearophile
