[latex3-commits] [l3svn] branch master updated (66ca83c -> 0dfa6c8)

[Joseph Wright]

On 23/11/2016 12:36, Bruno Le Floch wrote:
> Good job Joseph, switching from prop to tl and adding inheritance.  That
> latter point seems interesting!

Yes, though not currently quite as clever or efficient and that in
options (which is where the idea is from). I guess I need to think about
it a bit more.

> - If I read the code correctly the cs { \c_@@_type_root_tl
> \l_keys_path_tl } can only be undefined or equal to "choice".  Would it
> make sense to have a boolean perhaps?  Maybe not, if the real
> distinction is between defined and undefined (it might be annoying to
> have to test separately if a key is defined and if that bool is true/false).

At the moment it's only used for choices, but it could hold other data:
again, see options. Hsving two tests gets slow, hence wanting to remove
the prop usage, etc.

> - Showing the key doesn't tell us all the information (such as whether
> it is a choice key) anymore it seems?

Yes, I guess I should fix that :)

> - Inherit looks interesting.  Could you expand the doc?  Are keys
> defined previously for bar/ clobbered by "bar .inherit:n = foo" (I guess
> yes, or error message perhaps)?  Can further keys be defined (I guess
> yes)? What if "foo" is a key rather than a module containing keys?
> Basically can I use it to copy a key name as in the following?
> 
> \keys_set:nn { mymodule }
>   {
>     a4paper .bool_set:N = \l_aivpaper_bool ,
>     standardeuropeanpaper .inherit:n = a4paper
>   }
> 
> Should I think of it as "cp", or "ln -s" namely if the original is
> altered afterward, is the inheriting also altered?

It's path-based, not key-based. I'll work on this a bit more: I'm still
working out how best to implement, etc., given our key model (which is
not quite the same as pgf/options).

> - In the corresponding test file, only "Defining key module/key-one on
> line ..." appears, not the corresponding line "Defining key
> module2/path/key-one on line ..." that could be helpful to determine
> what keys are defined.  Of course from the implementation point of view
> the way it currently is is more natural.

Ah, but they are not defined! It's a lookup based approach at point of
use. (Aside: options stores data to allow the full key tree to be
printed from any point. Do we want that?)

Joseph