Re: multiple categories

[Peter Simons]

Guido Draheim writes:

 > [btw, next time I answer ape man style... :-)=)]

That's OK with me. :-)

But maybe you misunderstand the reason why I keep asking the same
questions repeatedly. It's not because I don't understand your reply
linguistically, it is because I have the feeling that your answer does
simply not address the question. Just looking at this very e-mail I am
replying to ...

I asked (note the emphasis):

 >> Do we NEED to put a macro into more than one category?

To which you reply:

 > (a) there is no need to use it, it's optional
 > (b) it is there when someone thinks it is good, and can use it.

You say, basically: "If we have it, we can use it if we want to." But
that is not d'accord with the facts, which are:

 - The current infrastructure does not allow putting a macro into
   multiple categories.

 - The legacy input format does not allow putting a macro into
   multiple categories.

 - The XML input format does not allow putting a macro into multiple
   categories.

Thus, the "if we have it ..." is wrong: We do not.

Thus, according to elementary logic, the "... we can use it if we want
to" is irrelevant, because the premises is wrong already.

Furthermore, it does not answer the question I asked, which is:

    Do we _NEED_ it?

If there is one lesson I have learned in over 10 years of software and
system design, it is: Don't add a feature unless you need it. Don't
make systems more complex than they need to be. A system is not
perfect, when there is nothing left to add, but when there is nothing
left to take away.

Adding this feature into the archive's infrastructure will require
me/us ...

 - to modify the software that generates the archive,

 - to modify the legacy file format (and its parser),

 - to modify the XML file format (and its parser), and

 - to re-asses ALL macros now and EVERY TIME a new category is added.

If that is not "adding complexity" I don't know what is.

Furthermore, the addition of this feature ...

 - makes the submission formats easier to screw up for the submitter,

 - thus increases the workload on the maintainers, and

 - makes the list of macros displayed per category longer.

Finally, let me say that ...

 - the original Autoconf package does not do it either.


So we have a _vast_ _array_ of disadvantages, whereas on the "gain
side", we have ...

 + it might make it easier for the user to find the macro.

Which, I replied, would probably be an effect we would get at almost
_no_ _additional_ _cost_ by adding a search engine to the web site,
and probably more so.

You also remarked that it would be nice to have for experimental
macros, to which I replied: Can't we just put them into the
"Candidate" category until they're ready for the submission procedure?

Please believe me that I am perfectly willing to add this and to
support this feature, but please give me a good reason for doing so
except for "it can't be difficult, so let's do it":

 > (c) I had not problem implanting it, so I guess it is not "complex".


On the topic of putting the m4sources into per-category subdirectories
rather than all-in-one:

 >> _Why_ is it not a good idea to put all the macros in one
 >> directory?

 > experience.

Well ... :-)


 > [It makes] no difference [for tools], where it is a difference to
 > humans.

>From my understanding, we have gathered the following points so far,
'+' denoting "subdirectory approach", '-' denoting "all-in-one":

 + Humans like it better than way.

 - The "aclocal" tool doesn't cope with it.

 - Paths change when a macro's category changes.

>From my understanding, we are talking exclusively about the way the
macros are installed on the system by the release archive, and in this
case, I think that the human preference for smaller, more manageable
portions of information does not outweigh the massively important
points in favor of all-in-one. Humans can use the HTML document set to
browse through the complete contents, sorted by category, "aclocal"
cannot. (In fact, I think "aclocal" not supporting it is a killer
argument in this case.)

Peter