PageRenderTime 13ms CodeModel.GetById 8ms RepoModel.GetById 0ms app.codeStats 0ms

Unknown | 60 lines | 50 code | 10 blank | 0 comment | 0 complexity | b117588d8af5ce3aa95d4cd0446fe0cd MD5 | raw file
  1. h1. Djehuty
  2. h2. A Framework Built on a Philosophy
  3. It is our belief that the importance lies not in the implementations of
  4. software, but rather the eventual usage of that software. If premature
  5. optimization is an evil of our trade, and since implementations once
  6. verified for correctness are merely useful for profiling, then premature
  7. implementation is just as evil.
  8. The proof of this is rather intuitive, and we will leave the exercise to
  9. the reader. A piece of this proof, however, is better said than left unknown.
  10. This is the fact that developers see the benefit in forking implementations.
  11. This will remain true. When implementations are forked, it is necessary to
  12. also fork the tests. Yet if one was going to code a new implementation of
  13. a procedure, why would they fork the implementations and not simply fork
  14. the tests? All implementations are rooted at a single set of tests.
  15. Furthermore, any implementation must be verifiable with the same tests. This
  16. implies that any implementation must share an interface. An interface, as
  17. defined here, is the view of the implementation seen by the user that
  18. provides expected public behaviors. The view of the implementation is known
  19. via the interface, and the public behavior is known via the test.
  20. Why is this important? It makes software engineering trivial. With the
  21. dependencies in place as described in the above paragraph, we know the
  22. order to produce any implementation. The correct development path is Tests
  23. then Interfaces then Implementations, where one will reuse as much to the
  24. left as possible. For any implementation, there is only one interface and
  25. one set of tests.
  26. When one writes a new piece of code, it must ask itself whether or not it is
  27. an implementation of an interface that already exists. If so, it will simply
  28. fork this interface and the tests and watch them fail. The developer will
  29. call it a day when the tests succeed. After this, two implementations may
  30. be profiled against one another.
  31. If an interface does not exist, a developer will write the tests. This is a
  32. good practice for many reasons. It will allow the developer to consider
  33. first the public behaviors of the implementation. These will suggest what needs
  34. to be hidden or revealed to the user. Knowing this will lend itself to
  35. developing the interface. At first the tests will fail. After the interface is
  36. written, the tests will fail, but they will be complete. Only the behavior
  37. is incorrect. After this point, it is the same as if the tests were forked.
  38. The developer will write the implementation until the tests succeed.
  39. Overall, this style of development will lead to a completely verifiable and
  40. extensible system. Implementations can be switched out either statically or
  41. dynamically with regard to profiling considerations or size considerations.
  42. This can happen without any further development concerns of the user. Also,
  43. there will be no concern over whether or not one implementation will alter
  44. the behavior of another. Each implementation will be equivalent in that
  45. their behaviors will be consistant.
  46. The Djehuty Framework is then not primarily concerned with being a set
  47. of libraries or a standard library. It is concerned with being a set of
  48. tests and interfaces. It is the goal of this project to allow innovation
  49. without headache and the ease of deployment, verifiability, and consistency
  50. in the realm of software development.