Re: RFC: Keywords instead of Section

[Erik Steffl <steffl@bigfoot.com>]

"Bernhard R. Link" wrote:
> 
> * Erik Steffl <steffl@bigfoot.com> [011118 01:35]:
> >   types:
> >     ui
> >     licence
> >
> >   keywords:
> >     x11, type=ui
> >     text, type=ui
> >     gpl, type=licence
> >     bsd, type=linence
> >
> >   it's basically normalizing data... it has number of advantages (I
> > guess that's obvious). you can e.g. check the type - it has to exists.
> > etc.
> 
> I think that the other solution is better. You have the type in the
> name, so the system could add cathegories without defining them. (e.g.
> some organisation like ximian could have additional local orthogonal
> types and you had no need to update the control-file which definies the
> types.)

  that's ridiculous. again, there has been lot of work done on problems
like this (see the databases (normalization), the data types in computer
languages etc.) for more elaborated reasons why.

  you need to have information on types separate, if nothing else to be
able to check the type - how do you know it's a valid type if you don't
have the list of types (think of the first category in given type). you
need to be albe to work with types independently, store some
metainformation about the type (at least description, see also (very
short) dicsussion on derived types etc.) etc.

  having the type sort of implicit in the name is a dirty hack that will
cause problem in the future. the things that are separate should be
separated - that's one of the basics of programming (if not THE basic
element of programming).

  btw: what you describing is extremely BAD thing. you don't want
anybody to screw up the types, they only have value if they are well
maintained. If it will prove absolutely neccessary to have custom types
we might add this possibility later (in some systematic way).

> And though the types are orthogonal, or better because of this, it might
> be a good solution, to have the same name under different types. e.g.
> ui:text and processes:text (this is a little bit contructed, but is
> there to show a possibility.)

  that possibility is there one way or another.

	erik