fix nested matlab package subdirectories

[rdeits]

Previously, if a package name contained a period, it would be replaced by the string '+/'. This would result in, for example,

mypackage.foo.bar

becoming

+mypackage+/foo+/bar

which does not create a valid matlab package. Instead, it should be replaced by '/+' to create

+mypackage/+foo/+bar

[jaeandersson]

I'm not able to test, but it looks like a legit fix. Not sure if nested packages work anyway since the files have to be generated in those locations. If it doesn't work, a better (temporary) fix would be to rename "." with "_". Cf. #55.

[yuriy-kozlov]

The mypackage.mysubpackage syntax works to create a +mypackage/+mysubpackage folder, but the class names in the generated files end up incorrect. MATLAB expects the full top level package name in every reference, and it doesn't seem to be possible to put an import statement above the class, so this fails in the subpackage .m files:

classdef MyClass < mysubpackage.AbstractClass

with a mysterious sounding error:

The specified superclass 'mysubpackage.AbstractClass' contains a parse error, cannot be found on MATLAB's search path, or is shadowed by another file with the same name.

For classes in mypackage.mysubpackage swig needs to generate: classdef MyClass < mypackage.mysubpackage.AbstractClass See this question: https://stackoverflow.com/questions/29544511/calling-functions-in-a-nested-package

A related question, why don't modules go in a subpackage directory? I expected this to create +mypackage/+mymodule: %module(package="mypackage") mymodule

[rdeits]

@yuriy-kozlov yeah, I believe I had a similar issue in the past. I'm no longer using Matlab, though, so I haven't investigated further.