| 1 | |
|---|
| 2 | Latest "Tidied" WCKER Version |
|---|
| 3 | ============================= |
|---|
| 4 | |
|---|
| 5 | The version of WCKER just checked in ( 12/02/05 ) has been tidied-up |
|---|
| 6 | and comments have been added at the request of Dave B. Hopefully, this |
|---|
| 7 | should make things easier for multi-person development. If you feel |
|---|
| 8 | any particular bit of additional tidying/commenting would be helpful |
|---|
| 9 | then let mw know. |
|---|
| 10 | |
|---|
| 11 | In fact I've taken the opportunity to object-orient (OO) the code a bit |
|---|
| 12 | more ... which is a natural way of tidying things up in Java. |
|---|
| 13 | As I mentioned to Tjitske there is a good argument for saying that OO |
|---|
| 14 | is a process rather than a state. |
|---|
| 15 | |
|---|
| 16 | OO Activities |
|---|
| 17 | ============ |
|---|
| 18 | |
|---|
| 19 | OO tidying mechanisms include: |
|---|
| 20 | |
|---|
| 21 | * making static code non-static |
|---|
| 22 | |
|---|
| 23 | basically instead of there being just |
|---|
| 24 | one permanent instance of code (i.e. static code) |
|---|
| 25 | it is automatically associated with |
|---|
| 26 | a dynamically created object instance (and |
|---|
| 27 | thereby has access to data items related to |
|---|
| 28 | that specific object). |
|---|
| 29 | |
|---|
| 30 | A "naive" but "revealing" way of restating this is |
|---|
| 31 | to say that OO code can reduce the number of explicit |
|---|
| 32 | parameters used. |
|---|
| 33 | |
|---|
| 34 | * introducing inheritance |
|---|
| 35 | |
|---|
| 36 | our WckerCache class is a natural extension of |
|---|
| 37 | Java's LinkedList class so I inserted explicit inheritance. |
|---|
| 38 | The effect was a beneficial simplification of the code. |
|---|
| 39 | |
|---|
| 40 | Unfortunately many of the SWT classes are designated as |
|---|
| 41 | final, which bars them from being inherited from. |
|---|
| 42 | Security arguments are involved ... but non-final classes |
|---|
| 43 | would have allowed me to object-orient WCKER much more. |
|---|
| 44 | |
|---|
| 45 | Javadoc |
|---|
| 46 | ======= |
|---|
| 47 | |
|---|
| 48 | I have been commenting using the "javadoc" conventions where appropriate. |
|---|
| 49 | javadoc is a tool which extracts documentation from java source comments. |
|---|
| 50 | |
|---|
| 51 | I have a little script "javadoc.run" which will generate the javadoc documentation |
|---|
| 52 | for WCKER under Linux. This is in the "ant" directory. It would be worthwhile |
|---|
| 53 | having a Windows equivalent, if this does not exist at present. |
|---|
| 54 | |
|---|
| 55 | Following the overall project philosophy, the javadoc documentation should |
|---|
| 56 | really be generated by "ant" so this is something we might want to look into. |
|---|
| 57 | |
|---|
| 58 | The problem with "ant" is that there is always a double learning curve: one |
|---|
| 59 | first has to learn how to use a tool (such as javadoc); one then has to learn |
|---|
| 60 | the appropriate XML tags to use within an ant file to capture the same actions! |
|---|
| 61 | |
|---|
| 62 | A brief net surf did NOT reveal what these tags might be for javadoc (if they |
|---|
| 63 | indeed exist). Of course one could try to go native with javadoc within ant |
|---|
| 64 | i.e. use system-level calls in the way one does in a makefile. |
|---|
