Re: [Gnu-arch-users] Features command for arch

[tomas]

On Wed, Sep 01, 2004 at 11:08:50PM -0700, Tom Lord wrote:
> 
>     > From: [various]
> 
>     [ A "features" feature is really desirable because several of us
>       are running into the kinds of problem that such a feature can 
>       solve. ]
> 
> 
> Ok, suppose that we accept that.... that still leaves the question of
> what *is* the "features" feature?

I would see it as a kind of database bound to this specific instance
of the application (but see below), providing some introspection.

> An answer implies/includes, to name a few things, how feature names
> are decided, who/how feature presense/absense is asserted, what valid
> feature names are, etc.

*If* (or when?) tla (the app) becomes extensible, a mechanism should
exist to exted the features database, so I could say
(provide 'signed-archives) or [horrors!] (provide 'max-speed 12).

> James' suggestion was something like named boolean flags, set I
> presume in a static array in some C file --- is that about right?

That seems about right to me (but see the silly example 'max-speed above).

> Even if I believe in the need for "features", that approach seems 
> a little random, to me, on at least a few grounds.
> 
> Such a table is easy to code up an understand, but also easy to make a
> mistake with while maintaining it (a task akin to double checking
> somebody's arithmetic at adding up a long column of numbers).
> When I balance my checkbook, I do the math by hand and double check
> with a calculator: I'm not sure we can expect people to be so careful
> with a centralized "features" table and I'm not sure what the
> "features" equivalent of a calculator (for double checking) would be.

No more and no less than peer review in this list. It's definitely as
difficult as maintaining source code in general.

> Next: I like to be frugal with new design add-ons.   If it's *really*
> necessary to add something new, hopefully it should solve lots of (or
> a very general) existing problems.   "Features" seems a bit isolated
> to me, in this context.   

It solves application introspection. If (when?) tla becomes extensible,
I'd expect extensions to make extensive use of this. Have a look at
Emacs.

> For example: revision libraries have parameter settings (e.g., the
> greedy and sparse flags).   Should "features" variables *really* be a
> fundamentally different thing?  or is there usefully some more general
> concept that would make "features" and revision library params the
> same thing?

It'd be the database context. In one case it is the specific instance
(say: version/configuration) of the application -- in the other case
it's the revlib. But yes -- in a way they are the same pattern.

I'd expect this to happen naturally when tla gets an extension language.

> And of course -- the old questions -- are features really just
> booleans?

See above, although I just came up with a silly example.

>             who controls the namespace of them and how?

It's part of the application. Or of the application extension. So it's
up to the application writer (or to the application extension writer).

Some basic conventions will have to be made up by the Tla Gods (and that's
you ;-)

At least Emacs is a place to look for prior experience.

Regards
-- tomás

pgpEgZ39Yw2G0.pgp
Description: PGP signature