Currently, in aas_inittoolbox there is a parsing of toolbox extraparameters. This assumes that the extraparameters for different toolboxes can be handled the same, whereas this is something that is actually quite specific for a particular toolbox. I.e. that if there are colons in the value, then that value should be split.
Since the extraparameters are specific for a particular toolbox, it makes more sense to put the handling of these parameters as a static method in the specific toolbox class. That also makes it more clear which toolboxes have known extraparameters.
The toolboxClass they all derive from would define a do-nothing default method, or even no method at all, since the method will only be called for classes that expect extraparameters.
In aas_inittoolbox it could then look something like
params = {};
if isfield(TBX,'extraparameters') && ~isempty(TBX.extraparameters)
parse_extra = str2func([tbxname 'Class.parseExtraParameters']);
params = parse_extra(TBX.extraparameters);
end
constr = str2func([tbxname 'Class']);
T = constr(TBX.dir,params{:});
Currently, in aas_inittoolbox there is a parsing of toolbox extraparameters. This assumes that the extraparameters for different toolboxes can be handled the same, whereas this is something that is actually quite specific for a particular toolbox. I.e. that if there are colons in the value, then that value should be split.
Since the extraparameters are specific for a particular toolbox, it makes more sense to put the handling of these parameters as a static method in the specific toolbox class. That also makes it more clear which toolboxes have known extraparameters.
The toolboxClass they all derive from would define a do-nothing default method, or even no method at all, since the method will only be called for classes that expect extraparameters.
In aas_inittoolbox it could then look something like