Re: More everything into the octave namespace

[Carnë Draug]

On 15 August 2016 at 23:59, John W. Eaton <address@hidden> wrote:
> On 08/11/2016 12:11 AM, Carnë Draug wrote:
>>
>> There's been a lot of stuff moved into the octave namespace.  Sounds
>> right to me that we move everything somewhere into the octave namespace.
>> Is that the plan?
>>
>> If we are heading that way, I'd prefer if it was all done in one go
>> (upcoming Octave 4.2 release), instead of gradually.  Makes it easier
>> to have a package that supports both versions, specially if it involves
>> renaming functions (maintaing a package that supports old and new Octave
>> versions when such changes happen is a burden.  If I can limit it to
>> the Octave 4.0 -> 4.2 transition that would be better).
>>
>> Should we start moving everything into namespaces?  And if so, what
>> should we leave in the octave namespace, and what goes into nested
>> namespaces?
>>
>> The doxygen docs were updated recently so we can have a list of the
>> current existing classes [1].
>>
>> Looking forward to start using octave::Array<T>.
>
>
> Yes, the plan is to move things to namespaces.
>
> I've been doing this incrementally because I want to change most names that
> are of the form "octave_foo" to be "octave::foo" instead.  So it's not as
> simple as just inserting "namespace octave {" at the top of every file and
> "}" at the bottom.
>

But that only applies to classes that are octave_foo.

Rik mentioned feature freeze the day after my original email so this
change won't go through to 4.4 anyway.  However, there's classes that
are new for Octave 4.2, and others that have changed since 4.0.  These
are the ones that could be moved right away.

For example, a lot of the classes in liboctave/numeric such as svd, qr, lu,
hess, chol, and qz have been templated.  People upgrading to 4.2 will have
to change their code to account for this.  If we don't put them in the right
namespace now, and if do it in Octave 4.4, people will have to be changing
their code again in 1 year (or whenever 4.4. comes out).

Same with the new classes in 4.2.  Better to get them in the right place
from the start than having to change them for 4.4.  That will be a bother
for us because we will need to keep backwards compatibility, and for our
users that need to change their code.