nested maps

[jrmxn]

Just a thought, but I wonder if you could integrate something like this?
https://github.com/RolandRitt/Matlab-NestedMap

I wasn't aware of matlab's map type, but it's a little annoying for accessing nested data as far as I can tell:
Used to be you could do:
c = cfg.a.b.c
Now you need to do

a = cfg('a')
b = a('b')
c = b('c')

to achieve the same thing.

[g-s-k]

Seems like a nice library! It would definitely make the implementation of this one simpler. That said, I am a little reluctant to introduce a dependency and make this library less generally interoperable. I will give it a try and let you know what I think.

[g-s-k]

Unfortunately it does not seem to work in Octave, and does not support assigning cell arrays as values, which is a pretty important feature for TOML. I will see if I can adapt it to work for this use case.

For now at least, a('b')('c')('d') is not a huge downgrade from a.b.c.d 🙂

[jrmxn]

At least in standard matlab, a('b')('c')('d') does not seem to work (I agree that would be fine).

% toml entry:
% [a.b]
% c = 1

x = toml.read('example_toml.toml');

a = x('a');
b = a('b');
c = b('c');
% c = 1  % works

x('a')('b')('c')
% Error: File: test_toml.m Line: 10 Column: 1
% Indexing with parentheses '()' must appear as the last operation of a valid indexing expression.

This probably goes against the spirit of your upgrade, but to get around this issue and to not have to change my previously written code, I am just converting the map back to a struct. As a solution this works fine for me:

function cfg_out = map_to_struct(cfg)
keys = cfg.keys;
cfg_out = struct;
for ix_key_outer = 1:length(keys)
    key = keys{ix_key_outer};
    value = cfg(key);
    if isa(value, 'containers.Map')
        cfg_out.(key) = map_to_struct(value);
    else
        cfg_out.(key) = value;
    end
end
end

[g-s-k]

I could include that utility in the library if you'd like.

The main reason for using Map is that TOML supports keys that are not valid field/variable names in MATLAB. Providing a function to translate to a more usable format (and fix those names in the process) makes sense for a library like this.

[jrmxn]

Up to you! I understand the rationale. Thanks for making this - I was using json before and this is much cleaner.