LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Sean Allred <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Sun, 31 Aug 2014 12:52:45 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (103 lines)
Hi Will,

> Like Frank said earlier, please don't take any lack of comment from me
> as disinterest --- it's unfortunately a busy time for me.

No worries at all --- I'm just happy that I've had a lull in my own work
to think about this some more.  So it goes :)

> Correct me if I'm being daft, but doesn't "requiredness" need to be
> checked at the template not object level? [...] Depending what type of
> template you choose to typeset the object, you may or may not end up
> using the various pieces of information.

Oh, you're absolutely right --- I never thought about it that way.  If
this idea is used, templates would definitely need to have some way of
declaring which object properties are required.  But perhaps...

> Or perhaps both objects and templates need to have a concept of which
> parameters are required, and only work together if they match
> appropriately.

...there could be a combination of the two, with the current concept of
'absolutely required' elements --- those properties without which the
object is meaningless (like a section title).  I think the 'matching'
idea might be a maintenance nightmare, but I think the idea would be
useful as some sort of 'inheritance' idea.

Then again, this is implementing a feature that is emphasizing an
already existing idea (assuming templates are given a sense of required
properties).  While I really like the "don't repeat yourself" of having
required properties at the object level, I'm not sure it's worth the
added language complexity.  I'm not saying it's a bad idea, I'm just
saying I can't quite envision how it would play out in the end.

* * *

Perhaps something like

    \DeclareObject { name }
      {
        first  : tokenlist ,
        middle : tokenlist ,
        last   : tokenlist ,
      }

    \DeclareTemplateInterface { name } { full-name }
      { first, last }
      {
        reversed           : boolean   ,
        first-name-format  : tokenlist ,
        middle-name-format : tokenlist ,
        last-name-format   : tokenlist ,
      }

I would note that this does fit well with the existing xtemplate
interface.  Normally, we would issue

    \DeclareTemplateInterface { name } { full-name } { 2 } { ... }

to indicate that there are two required arguments.  The required
arguments listed in the above syntax is (conveniently) in the same
position.

My immediate concern with this is the idea of (co-)dependencies.
Perhaps something like this can express those:

    \DeclareTemplateInterface { name } { full }
      { last }
      { middle : first }
      {
        reversed           : boolean   ,
        first-name-format  : tokenlist ,
        middle-name-format : tokenlist ,
        last-name-format   : tokenlist ,
      }

Where 'last' is the only *required* property and to provide 'middle',
you must provide 'first'.  Perhaps lt3graph can be leveraged?

Just thinking out loud here.  Perhaps this kind of co-dependency isn't
really needed to begin with, but I suppose it's something to keep in
mind.  If this was used, there would have to be some sort of
dependency-cycle checking going on at declaration time, but that's just
a detail.

* * *

I'm interested in what you're thinking though:

> Or perhaps both objects and templates need to have a concept of which
> parameters are required, and only work together if they match
> appropriately.

What kind of syntax do you have in mind?  It might make more sense.

* * *

Thanks again (everyone --- past, present, future) for giving this a
hearing and offering your own ideas. :)

Best,
Sean

ATOM RSS1 RSS2