octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pkg.m status and question


From: Rik
Subject: Re: pkg.m status and question
Date: Tue, 7 Jan 2020 12:23:03 -0800

On 01/07/2020 09:00 AM, address@hidden wrote:
Subject:
Re: pkg.m status and question
From:
Juan Pablo Carbajal <address@hidden>
Date:
01/07/2020 02:24 AM
To:
Mike Miller <address@hidden>
CC:
Maintainers GNU Octave <address@hidden>
List-Post:
<mailto:address@hidden>
Precedence:
list
MIME-Version:
1.0
References:
<address@hidden> <address@hidden> <address@hidden> <address@hidden>
In-Reply-To:
<address@hidden>
Message-ID:
<address@hidden>
Content-Type:
text/plain; charset="UTF-8"
Message:
3

On Mon, Jan 06, 2020 at 23:34:06 +0100, Juan Pablo Carbajal wrote:
Int he direction of making pkg handling better, we should have a
uniform structure for the DESC file with all possible fields, any DESC
file that does not fill one leaves the default value of NA.
I humbly suggest that the package description struct should have some
number of required fields, but any number of user-defined optional
fields that can be added to the package as needed. There is no way to
define all possible fields. That's the way it works now, please don't
make it more restrictive.
If user can add arbitrary fields, then there is no standard.
My proposition is that we manage to get this flexible enough that if
new fileds are good ideas, the stadard can be extended.
We can also always have a "UserDefined" field in the basic structure
that collects all user define fields that are not part of the
standard. This goes close to the idea of Philip.

Functions that process this information need to process the standard
fields, but can do whatever they wish with th einfo inside
"UsedDefined".
This gives a lot of uniformity in the code, and probably the
identification of lots of boiler plate sections and good practises.

my two cents
I'm sensitive to Mike's original argument.  The future is hard to predict, and deciding today on the number, name, and type of fields that will exist for all time is too difficult.  In some manner, the architecture must support change.  I am agnostic as to whether that flexibility is because each struct lives alone as a cell element, or because there is a modifiable "UserDefined" field.

--Rik

reply via email to

[Prev in Thread] Current Thread [Next in Thread]