Concerning \installparameterhashhandler and family

Concerning \installparameterhashhandler and family

[Jairo A. del Rio via ntg-context]

[-- Attachment #1.1: Type: text/plain, Size: 507 bytes --]

Hi. Reading at mult-aux.mkxl, I've seen command handlers define, among
others,  \installparameterhashhandler, However, in files such as those
related with symbol management, only \installparameterhandler and
\installsetuphandler are. When writing basic modules, sometimes only the
"raw" macros above are actually needed. So, what are "parameterset",
"hashhander", "rootparameterhandler", etc. for? Where would they ease
module writing? Thank you a lot and sorry for the long question.

Best regards,

Jairo

[-- Attachment #1.2: Type: text/html, Size: 612 bytes --]

[-- Attachment #2: Type: text/plain, Size: 493 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Concerning \installparameterhashhandler and family

[Hans Hagen via ntg-context]

On 11/9/2021 8:01 PM, Jairo A. del Rio via ntg-context wrote:
> Hi. Reading at mult-aux.mkxl, I've seen command handlers define, among 
> others,  \installparameterhashhandler, However, in files such as those 
> related with symbol management, only \installparameterhandler and 
> \installsetuphandler are. When writing basic modules, sometimes only the 
> "raw" macros above are actually needed. So, what are "parameterset", 
> "hashhander", "rootparameterhandler", etc. for? Where would they ease 
> module writing? Thank you a lot and sorry for the long question.
The ones you mention are the lowest level ones and mechanisms that use 
them are oned that don't really have much to manage (like symbols and 
languages and fonts and so, these are core mechanisms on their own and 
need additional interfaces. There's also the matter of performance: 
anything key/value driven can have a performance hit so the more one 
wraps the worse it can get. (The mkii and mkiv/lmtx methods differe 
fundamentally, where in principle the mkii approach is faster but in 
practice mkiv/lmtx works out better. A typical case where usage in the 
end determines performance more than the implementation.)

For modules: don't go too low level. Not all helpers in modules like 
mult-aux are meant for usage outside well known situations. Just like 
some low level helpers in syst-aux stay around for compatibility.

In fact, one of the ideas behind luametatex/lmtx is to get rid of 
"complex" middle layers where the language itself can do it, so:

\protected\def\foo[#1]{\dosingleempty\dofoo}

\def\dofoo[#1]{...}

in mkii/mkiv can now be:

\tolerant\protected\def\foo[#1]{...}

(1) less code
(2) somewhat faster
(3) looks nicer (for me much is about looks)

but I guess that you already know that,

Hans


-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________