[latex3-commits] [git/LaTeX3-latex3-latex2e] prototype: Add prototype discussion points (cd365c59)

[Joseph Wright]

Repository : https://github.com/latex3/latex2e
On branch  : prototype
Link       : https://github.com/latex3/latex2e/commit/cd365c59a6637aa188064e5f8d3bd94d8dd3f545

>---------------------------------------------------------------

commit cd365c59a6637aa188064e5f8d3bd94d8dd3f545
Author: Joseph Wright <joseph.wright at morningstar2.co.uk>
Date:   Wed Mar 9 14:00:42 2022 +0000

    Add prototype discussion points


>---------------------------------------------------------------

cd365c59a6637aa188064e5f8d3bd94d8dd3f545
 required/latex-lab/latex-lab-prototype.dtx | 63 ++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/required/latex-lab/latex-lab-prototype.dtx b/required/latex-lab/latex-lab-prototype.dtx
index 2d3045e2..5e1640bf 100644
--- a/required/latex-lab/latex-lab-prototype.dtx
+++ b/required/latex-lab/latex-lab-prototype.dtx
@@ -315,6 +315,69 @@
 %   \end{syntax}
 % \end{function}
 %
+% \section{Open questions and comparison with \pkg{xtemplate}}
+%
+% The approach here is modelled on that from \pkg{xtemplate}, but since it uses
+% \pkg{l3keys} rather than dedicated key handling, there are some differences.
+% There is also a simplification in that collections are not supported.
+%
+% The various open questions, including those linked to \pkg{xtemplate}
+% concepts, are collected here.
+%
+% \subsection{Module name}
+%
+% This is currently open for ideas: traditionally \texttt{template} has
+% been used. This may link to the need for both templates and instances
+% (\emph{vide infra}).
+%
+% \subsection{Design-level names}
+%
+% These are currently not provided. That allows both this code and
+% \pkg{xtemplate} to be loaded in the same document. We will likely want
+% to decide on these names: they could for example include
+% \texttt{Prototype} or \texttt{Design}, or could use the existing
+% \pkg{xtemplate} if a compatibility approach can be designed.
+%
+% \subsection{Objects}
+%
+% Is this name clear? A possible alternative is `element'.
+%
+% \subsection{Efficiency and repetition of key setting}
+%
+% In the \pkg{xtemplate} implementation, keys values are stored in property
+% lists before being applied. This means that when creating an instance, the
+% template defaults can be replaced entirely by any instance values. In
+% contrast, the approach here simply precompiles all of the template defaults,
+% then appends the precompiled list from the instance. Some variables are
+% therefore set twice. More importantly, this means that arbitrary code
+% could be executed twice: authors need to be aware of this.
+%
+% \subsection{Key ordering}
+%
+% Linked to the previous idea, in \pkg{xtemplate} keys are set in the
+% order they are declared in the setup. In contrast, using \pkg{l3keys}
+% they are set in the order the keys are given in the input. Is this OK?
+%
+% \subsection{Setting defaults}
+%
+% The current approach requires setting the defaults separately from
+% the key creation. That means listing keys twice. However, it also
+% avoids further overloading of the keyval setup. Is this reasonable?
+%
+% \subsection{The need for templates and instances}
+%
+% In \pkg{xtemplate}, storing keys in a \texttt{prop} means that there
+% is a real efficiency when creating an instance. In contrast, using
+% precompiled keys here, creating a template and creating an instance
+% are almost identical. Could we drop the distinction? That would then
+% work well if we allowed instances to be derived from others: effectively
+% the same as instances from templates, but with a `flatter' approach.
+%
+% \subsection{Collections}
+%
+% These are not implemented at all: we likely want a new approach to
+% contexts.
+%
 % \end{documentation}
 %
 % \begin{implementation}