--- al_todo.txt 2002/10/18 13:53:28 1.2
+++ al_todo.txt 2002/10/18 14:52:38 1.3
@@ -152,3 +152,31 @@
x mlelstv:
wenn schon dann XML namespaces.... >-)
+o rse:
+ al_rc_t al_txalloc (al_t *al, al_tx_t **tx);
+ al_rc_t al_txfree (al_t *al, al_tx_t *tx);
+ -al_rc_t al_traverse (al_t *al, size_t off, size_t n, al_td_t dir, al_tx_t *tx);
+ +al_rc_t al_traverse (al_t *al, al_tx_t *tx, size_t off, size_t n, al_td_t dir);
+ al_rc_t al_traverse_next(al_t *al, al_tx_t *tx, al_chunk_t **alcp);
+ al_rc_t al_traverse_end (al_t *al, al_tx_t *tx, int final);
+
+ mlelstv:
+ parameter order is: object ptr(if any), input parameters, output parameters
+
+ rse:
+ Nun, generell ist deine "obj-ptr, input[, ...], output[, ...]"
+ Reihenfolge voellig ok. Der Punkt ist nur, dasz es eigentlich
+ "obj-ptr[, ...], input, [,...], output, [,...]" ist, sprich es
+ kann durchaus bei Sub-APIs mehrere Object Pointer geben. Und
+ genau das ist bei dir ja der Fall IMHO. Denn das al_tx_t und die
+ Functions al_txalloc, al_txfree, al_traverse, al_traverse_next und
+ al_traverse_end bilden bei dir ja eine solche Sub-API. Und deswegen
+ wuerde ich das al_tx_t auch als zweites Argument bei al_traverse
+ sehen. Denn obendrein: wenn es man es genau nimmt, ist das al_tx_t
+ ja nicht nur bei al_traverse ein Output Parameter, denn die anderen
+ Funktionen aendern ihn ja auch ab. Wenn man also streng zwischen Input
+ und Output-Parameters unterscheidet, dann duerften Input Parameter
+ also nie veraendert werden (wenn sie nicht eh per Kopie reingehen).
+ Die Input/Output-Regel ist also streng genommen bereits durch
+ al_traverse_next gebrochen IMHO.
+
|
