Having circulated a draft of my article on dynamically linked functions
to some of you, I am moved to go on-list to explore one of the points
that has come up:
In essence, there is a question as to whether it is worthwhile
documenting the octave classes whilst
(i) a potential API or a stable mex library might be in the wings; and
(ii) the underlying representation of octave classes might change?
My reaction to (i) is that it seems to me that the first layer of octave
derived classes, such as matrix, ColumnVector, Cell and all the others,
together with octave_value and octave_value_list, form a rather good
API that needs documenting.
The corollary to this responds to (ii). It is that derived classes,
like Array, idx_vector and so on should, not be considered to be part of
the API (except implicitly through fortran_vec(), for example) , in
order that they can be modified in the future. Is this not the strength
of implementing octave in C++? The example of the use of a transpose
flag, rather than a physical transpose was mentioned. It would still be
natural to have a Matrix::transpose(), either inherited or as a class
member, would it not?