On Fri, Apr 2, 2010 at 5:19 AM, Vicente Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Gottlob Frege wrote:
On 3/31/10, Andrew Sutton <andrew.n.sutton@gmail.com> wrote:
Ok I completety get it now. So, thumb up for me :)
This seems like an interesting idea. I think it might factor nicely into my PhD dissertation which seems to involve both concepts and software maintenance issues.
Andrew Sutton andrew.n.sutton@gmail.com
I've been thinking lately that concepts and test cases and APIs and documentation are all intertwined.
D (language) allows unit tests to be coded right beside the implementation code. Concepts describe constraints that must be successfully 'passed' - like unit tests.
APIs and documentation often include example-code.
unit tests are often the best examples, and often the best^H^H^H^H only documentation of the API - ie the API does this - and is suppose to do this - because that's what the unit tests test for.
Docs can be written in the code comments (eg javadocs), but concepts and unit tests (particularly in D) are right in the code.
Obviously very vague ideas at the moment. Maybe I should read up on Knuth's WEB again...
Tony, You lost me. Where do you want to go?
Best, Vicente
Well, considering it was only a vague idea that has been floating around in the back of my head, and that I wrote the email at 2am, I'm not surprised it made little sense. Let me try again. And start by saying, and this is somewhat my point, I don't know where it goes. Maybe it is something a grad student can take and run with. Or if someone wants to pay my bills and feed my family, I'll investigate it further :-) (I should also mention that it has probably veered somewhat from your original post about 'Code Features' and Meyers' article, and had more to do with Andrew Sutton's response and mention of concepts and software maintenance. But even 'Code Features' was about verifying necessary constraints, so I suppose it applies as well. As I will hopefully explain in the following...) The idea(s) is that concepts (ala C++) are a way to *verify* that the types passed in meet the necessary requirements. Now this verification is somewhat weak (more syntactic than semantic) but let's call it verification for now. (For more semantic checking, see David Musser's (of STL fame) recent work on provability algorithms.) Unit tests are also a form of verification. So there seems to be a possible avenue of research here - using concepts as unit tests, or merging the 2 ideas. I think the D language, with its inherent support for unit tests, and with its easy handling of compile-time code, might be a an interesting testbed for some of these ideas. Unit tests are also a form of documentation. Sometimes the only documentation, or at least the only accurate documentation - ie if the docs say that the sort function is a stable-sort, but the unit-tests don't test for 'stability' then I'd be wary as to whether the sort really is stable - maybe it once was, but via 'fixes' and 'optimizations' is no longer meeting its claims. And concepts are also a form of documentation. sort<RandomAccessContainer c, StrictWeakOrder comparitor>()... *documents* the requirements for the types necessary for sorting. And in general, we are always striving for 'self-documenting code'. (Again this would be a place to mention Knuth and his WEB language, which somewhat turns the code-document relationship on its head.) So they all seem to be interrelated. Makes me start to think that over time we might be able to merge them into something more powerful. I have no idea what that would end up looking like. As a start, maybe if the h file or interface of the class was - member functions, etc - which we have now - documentation - unit tests - concepts in some consistent language, we'd have more maintainable code... And importantly, they would need to be interrelated/merged enough that the documentation *could not!* get out of sync with the unit tests, which got out of sync with the concepts, which was out of sync with the member functions. ie if it is not consistent, it doesn't compile. The more merged those items are, the easier it would be to stay consistent. If I need to repeat that 'the comparison is a strict weak order' or 'the function leaves the container sorted' in the code, comments, unit tests, and concepts, then I'll go crazy (as I do now!). I'd rather say it once. Tony