Move to package structure

[caiw]

Right now there is the potential for function name conflicts with other matlab code or toolboxes.

To mitigate this we can use Matlab namespacing.

[caiw]

I am working on this on the branch move-to-package-structure. However there is a snag.

If a Matlab package directory (+rsa/) has subdirectories, their functions don't get included in the package.

I guess my "minimum working example" for packages was too minimum, sorry.

There are some ways around this.

1. Functions to be addressed from recipe files live in +rsa/ and the "engine" functions live in +rsa/private/, which is a special directory which does get included.
   • These functions then can't be accessed from outside the package, which isn't great. Several engine functions are currently referenced from the demo recipes, which somewhat breaks the separation we were going for, but this is inevitable.
2. Subdirectories can be included if they too have a +. So we could break the toolbox up into +rsa/ and +rsa/+core/, where +rsa/ is for main "top-level" functions (modules) and +rsa/+core/ is for everything else (engine functions).
   • This is what I've done so far.
3. We go further, and impose the proposed hierarchy in a package tree.
   • Something like:
     • +rsa/+fmri for fMRI-specific code
     • +rsa/+stats/ for statistics code
     • +rsa/+vis/ for visualisation code
     • +rsa/+sl/ for searchlight code
     • +rsa/+utils/ for useful little functions
   • The benefit of this is that we may be wanting this kind of directory tree anyway, and it makes the structure of the toolbox very clear.
   • The drawback is that we either have addressing of functions: rsa.vis.showRDMs(...), rsa.utils.scale01(...)
   • Or we have large import blocks as needed:

function myFunc()
    import rsa.*
    import rsa.utils.*
    import rsa.fmri.*
    import rsa.vis.*

    ...
end

Alternatively we can give up on this idea and go to the rsa_* renaming scheme, with all of its associated issues.

My personal preference is for option 3, where we have fully hierarchical namespaces, as the overhead of addressing namespaces is something I am very used to in other languages, and I think it is the semantically cleanest option.

I will wait for some discussion here and then continue work as appropriate.

[caiw]

Option 3 was agreed over email. This is now in pr #4.

[iancharest]

this issue should be closed as this has been done and merged. closing now. reopen if anything.