octave API and present octave classes

[Paul Thomas]

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?

Regards

Paul T