Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v1075.2)
Content-Transfer-Encoding: 7bit
References: <19209.8773.325233.396932@morse.mittelbach-online.de>
Message-ID:  <351444E2-A094-44F3-B988-065D3D0156DA@gmail.com>
Date:         Mon, 23 Nov 2009 10:04:27 +1030
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Will Robertson <wspr81@GMAIL.COM>
Subject: Re: object type / instance arguments
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <19209.8773.325233.396932@morse.mittelbach-online.de>
Precedence: list
Status: R

Hi Frank,

Long email :)
I'm only able to reply briefly I'm afraid.

On 22/11/2009, at 10:06 PM, Frank Mittelbach wrote:

> With more complex object types I clearly can see the advantages of  
> this
> method, with more simpler types I'm not so sure though, partly  
> because of the
> overhead in processing. That makes me leaning towards a dual  
> approach (also
> suggested by Lars at one point if I remember correctly), ie have the  
> most
> important arguments mandatory but allow for an additional dictionary  
> to be
> passed along and queried as needed.

Agreed.

> What is the signature of an object type?
> ========================================

[...]

> a) the object type defines the semantic of an object (of that type)  
> including
>   the semantics of its mandatory arguments. The optional dictionary  
> is not
>   considered and can be used in different ways by objects belonging  
> to the
>   same object type.
>
> b) the dictionary is part of the definition of an object type, ie  
> the keys it
>   can contain and their semantics are defined by it, i.e., two  
> objects only
>   belong to the same object type if their semantics are the same on  
> all levels
>
> c) kind of in between: the object type can define the semantics of  
> certain keys
>   in which case all objects of this type have to support exactly that
>   interpretation, however an object is free to accept/interpret  
> additional
>   keys.

I think (c) here. This jibes well with the bibtex-like approach as well.


> How should the dictionary be specified?
> =======================================
>
>  \foo {...} {...}
>       {
>        \ToDictionary{key1}{val1}
>        \ToDictionary{key2}{val2}
>        ...
>        \ToDictionary{keyn}{valn}
>       }

I like this one.
(Whether "\ToDictionary" or whatever doesn't matter for now.)


> I wouldn't want to directly use property lists from the expl3  
> language at that
> point for two reasons:
>
> - on the level the instances are used (ie the designer level and  
> above I
>   don't like to mix in expl3 syntax

That alone is a good enough reason :)


> Should there be some inheritance of dictionaries?
> =================================================
>
> a) the dictionary is build directly before or when an instance is  
> called and
>   it is cleared when one gets to \AssignKeys in the template code
>
> b) the dictionary definitions obey grouping and this way can be  
> passed from
>   one  instance to the next, e.g., the dictionary coming with a  
> heading can
>   be made available to the instance implementing the toc entry (thus  
> author,
>   abstract, what-have-you that came in the dictionary to the heading  
> is also
>   available in the toc for inspection
>
> of course, instead of automatic inheritance one might be better off  
> if it is a
> conscious decision in the template whether or not its dictionary is  
> being made
> available for later.

I think the simple approach of having no inheritance works best for  
now. As you say, if it's necessary then it can be added by storing the  
values you want to use later.

-- Will