pkg.m status and question

[PhilipNienhuis]

Hi,

The last weeks I've been poking around in pkg.m, not so much for fun but
rather for fixing issues that I felt were in my way. (Other users &
developers seemed to have lived with it for years now). Along the way I
received several comments that pkg.m and private helper functions constitute
an unduly complicated beast. Explicitly or implicitly it emerged that the
conceived complexity is a big motive to stay as far away from pkg.m as
possible.
IMO the complexity largely mimics the way add-on packages are implemented:
local and global packages; standardized locations or separate locations for
.m files and/or binary modules; don't get me started about package
dependencies. On top of that I have the impression that some OF packages
themselves have a complicated setup that must somehow be accommodated in
Octave's package structure; either Octave's package structure is too limited
or those packages are just too complicated, I don't know.
But I can agree with comments that the code could be improved.

At this moment  I just have a question, mainly aimed at the previous
developers of pkg.m, about a very practical point:

The octave_packages file(-s, local and global) are just .mat files. The
setup is a cell array and each cell contains a scalar struct for each
package.
==> Question: why is it a cell array of scalar structs in the first place?
Why not a regular struct array?

The only reasons I can come up are these:
* That way each package can have a struct with dedicated fields when some
package requires so.
* It was always that way, perhaps by technical constraints in times gone by
and no one bothered.

My motive for asking is that this setup of package info makes for needlessly
inefficient and complicated code. For each tiny action the relevant structs
have to be unwrapped first. IMO dealing with a struct array rather than cell
array of structs would make the code much more transparent and much more
efficient as well.

Any thoughts?

Thanks,
Philip






--
Sent from: https://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html