[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-recutils] Field predefined types
From: |
OLLIER Jean-François |
Subject: |
Re: [bug-recutils] Field predefined types |
Date: |
Tue, 1 Feb 2011 22:42:55 +0100 |
User-agent: |
Mutt/1.4.2.2i |
Yes Jose, your solution can be very usefull, I just need to create a phony
record
where I will declare all the field types I need;
%rec mytypes
%typedef type1 /xxx/
%typedef type2 /yyy/
It doesn't matter if this record is never instanciated, does it?
However, I went further in this reflexion ( my laziness always pushes
me to imagine new ways of re-use, to make more with less efforts ),
and I am thinking about some variations of today's discussed concepts,
while trying to keep compliant whith the recutils philosophy ('human readable
records').
I will introduce them to you in a few time, and today's ones may be part of the
whole picture.
Thanks again for your comments.
Jean-François
On Tue, Feb 01, 2011 at 03:10:50PM +0100, Jose E. Marchesi wrote:
>
> Hi JF.
>
> I would like to expose an idea of mine; Its objective is to help
> lazy people as I to write repetitive descriptors. We already have
> predefined field types, like "date" and "email", I suggest to allow
> the declaration of user-predefined types.
>
> That is a very good idea, to support named user-defined types. However,
> your prososed %define directive would invalidate one of the premises of
> the format: rec data is a sequence of record sets, and record sets are
> sequences of records. It follows that the only contents allowed in a
> rec file are comments and records. The line:
>
> %define FullName regexp /^[A-Z][a-zA-Z-]+ [A-Z][a-zA-Z-]+$/
>
> is neither a comment or a record. Even if we turn it into a field, and
> place the field before the other record sets:
>
> /
> | %define: FullName int
> |
> | %rec: foo
> | ...
> |
> | %rec: bar
> |
> | ...
> \
>
> The record containing %define would pertain to the "default" unnamed
> record set, since it is not a record descriptor: it is lacking the %rec:
> field.
>
> I have a suggestion for a different implementation of the same
> principle, that would fit better in the recfiles design. This solution
> is based in two additions to the format:
>
> 1) A %typedef special field, that can be used to define named user
> defined types. As with any other special field, it shall appear in a
> record descriptor and will have effect in the records contained in
> the record set. The synopsis is:
>
> %typedef: TYPE_NAME TYPE_DESCRIPTION
>
> where TYPE_NAME is the name of the type. It shall follow the same
> rules than field name parts. The type name can be used in any place
> where a type description is expected.
>
> For example:
>
> %rec: Person
> %typedef: IdNumber regexp /[0-9]{5}[a-zA-Z]/
> %type: Id IdNumber
> %type: OldId IdNumber
>
> Note how both Id and OldId are defined using the same user defined
> type 'IdNumber'.
>
> Since a type name can appear anywhere a type description is required,
> it is possible to "chain" typedefs:
>
> %typedef: BasicCode regexp /../
> %typedef: PersonId BasicCode
> %typedef: GroupId BasicCode
>
> 2) The ability of referring to types defined in other record sets. We
> could do it by allowing the usage of type names like:
>
> RECORD_TYPE:TYPE_NAME
>
> For example:
>
> %rec: Person
> %typedef: PersonId regexp /.../
> %type: Id PersonId
> ...
>
> %rec: Group
> %type: Id Person:PersonId
>
> Note that it would not be allowed to such compound type names in
> %typedef.
>
> What do you think?
>
> --
> Jose E. Marchesi address@hidden
> GNU Project http://www.gnu.org
--
Jean-François OLLIER
mailto:address@hidden