[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pkg.m status and question
From: |
Mike Miller |
Subject: |
Re: pkg.m status and question |
Date: |
Mon, 6 Jan 2020 19:54:10 -0800 |
On Mon, Jan 06, 2020 at 23:44:24 +0100, Philip Nienhuis wrote:
> We need a basic struct with all required fields that are of the same type
> for all packages.
> All fields that are heterogeneous (not required for each package and/or not
> used by the package manager) go in substructs or cell arrays in a dedicated
> field of the main struct. That way we move heterogeneity from the outside
> wrapper into a much less prominent location inside, out of the way of
> regular package manager operations.
This seems unnecessarily awkward for the task at hand. Are you
suggesting a package description struct might be accessed like this
d = pkg ("list", "foo")
d.name
d.version
d.maintainer
d.extensions
d.extensions.citation
d.extensions.wiki
d.extensions.("bug-tracker")
or like this
for i = 1:length (d.optionalfields)
d.optionalfields{i}.keyword
d.optionalfields{i}.value
endfor
Does it really seem like a worthwhile tradeoff to introduce a new nested
struct or array of optional properties just to have a fixed base
structure definition that can be stored in an array? No, that seems even
more complicated to me. This is software, after all, not a packet
protocol.
I guess internally you can store it however you feel is best, but the
user should have access to an easy flat structure that contains all of
the package metadata, both required and optional, as it is now.
--
mike
signature.asc
Description: PGP signature