Re: pkg.m status and question

[Rik]

On 01/10/2020 02:51 AM, Juan Pablo Carbajal wrote:
>> 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.
> Predicting the future here has no role. the point is that you need to
> define a standard for your package distribution and management system.
> Goals of the standard:
> 1. Easy to extend (here are all your concerns about the future
> covered, there is no attempt to predcit the future [1], but to be able
> to adapt to it)
> 2. Uniform and stable. The uniformity allows us to produce code that
> anybody can use for they packages (if the follow the standard). The
> stability is just a desire to avoid too much maintenance
>
> Hence, the DESC fiel should have standard (required) fiels (it has
> already), and the user can add more arbitrary fields, but those will
> be parsed inot a uniform field (that is always present in the program
> representation of the DESC file (e.g. a structure)) which could be
> called "UserDefined". Standard code will not parse that field, but the
> user's functions can use it in the context of their packages.
>
> I do not think we have a differnet opinon here, but it seems you are
> opposing to something in my proposal that I cannot pin-down.

I think you may be arguing with someone else.  I only wrote one e-mail on
the subject which was the one you quoted.  As I remarked, I don't care
about the actual implementation (cell array, DESC file, etc.) as long as
the software architecture chosen is flexible rather than brittle.  A
current example of the trend from another area of computer science is
databases, where programmers are moving away from the fixed schema of
relational databases and implementing NoSQL dabatases instead.
 
>
> [1] It is funny that you guys are worried about the future,

I'm not one of "you guys" whoever they are.  I haven't been following this
thread except for the one general comment I made.

--Rik