Re: GSOC 2013 - FEM LIBRARY

[John W. Eaton]

On 05/31/2013 01:43 PM, Júlio Hoffimann wrote:

> oct::array<T>
> oct::operators::add<T,U> (read altogether as "octoperators", cool huh?!)

I'm not a big fan of these extra namespace layers.  It seems like 
needless complication.  Maybe it wouldn't make things harder for us when 
writing Octave code as inside the Octave sources we will probably just 
have using declarations for all our own namespaces.  But for people who 
don't care about Octave internals and who are also just using a few 
functions from Octave and don't want to insert using declarations for 
the Octave namespaces, it will probably become tedious to try to 
remember which functions are in which of the nested namespaces.  And, 
even if it is not harder for us to write code for Octave, it will be 
harder for us to move a function from one nested namespace to another 
(even MORE backward compatibility worries).

This reminds me of how we caved in to the pressure from some novice 
Octave developers and rearranged the Octave source tree last year.  The 
novices thought the number of files in the liboctave and src directories 
was intimidating.  And they assumed that it would be easier to see the 
structure of the sources if they were split up into more logical groups 
of functions.  Since then, I've had nothing but trouble finding files. 
I don't think the extra directory levels in liboctave and libinterp 
really helped me at all, and they probably just make it more confusing 
for people -- WTF is the difference between libinterp/corefcn and 
libinterp/interp-core?

jwe