bug-recutils
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]