I’m working on hugo#3042 ( PR here ) and wanted to share a plan for which packages the existing funcs could be moved to. I’m soliciting feedback. Before every freaks out and grabs their pitchforks, I’m not planning to deprecate all the functions you’re used to using. My goal is to move the Go code …

I will look closer later, it looks very very good in general. A few comments: time: It is the obvious choice. Let us assume for argument’s sake that we pull this in after we release Hugo 0.20 (which I guess makes sense). Then we can do a “hard” deprecation of time (rename it) and just do the NS ch…

cast and transform sound very similar even if cast is mostly only used in the context of data types lang seems to be a container for all i18n funcs. In the future we might add functions to format currencies, dates etc. Would you add them here, in transform or date? net: getCSV and getJSON can load …

Changes to OP: base split into collections and operators (still need to decide on default func) net changed to data partial changed to templates split func moved to strings More options: Rename cast to types? Rename lang to translation or translate? More questions: time func moved to…

No pitchfork here, and I’m with “not deprecating all the functions you’re used to using,” but per the question I asked you in the docs repo , is the long-term goal to change actual usage down the road for users (i.e., will these functions actually be called on the page with their respective ns)? Aga…

[image] moorereason: I meant for lang to include localization in the future. Does it make sense to split i18n and l10n into separate packages or can they coexist in the same package? Also, I was trying to avoid a naming conflict with the i18n func Because they are closely related we could g…

[image] rdwatters: is the long-term goal to change actual usage down the road for users (i.e., will these functions actually be called on the page with their respective ns)? Yes. Users will be able to use strings.Split in their templates. does it make sense to group under operators since i…

[image] moorereason: operators The operators NS is closely related to the math NS and it’s name could imply the that it also contains operators like sub and mul. Alternatively, I would suggest comperators as an alternative.

[image] rdwatters: No pitchfork here, and I’m with “not deprecating all the functions you’re used to using,” but per the question I asked you in the docs repo, is the long-term goal to change actual usage down the road for users (i.e., will these functions actually be called on the page with the…

I agree. operators is too generic. They’re really comparison operators, always returning a bool, but they deal with more than just numerical comparisons. I’ve renamed operators to compare.

Plan for namespacing template funcs

dev

digitalcraftsman March 15, 2017, 3:43pm 6

Because they are closely related we could group them in the same namespace.

NEW DOCS SITE! Need feedback!

Topic		Replies	Views
Why doesn't Hugo use Liquid feature	14	4843	September 5, 2018
Hugo benchmarks: Go 1.12 vs Go 1.13 Announcements	3	2592	September 3, 2019
String Utilities? feature	14	4295	March 21, 2015
Deprecate markdownify? feature	44	3537	February 14, 2025
Roadmap to Hugo v1.0 feature	36	9802	February 20, 2016

Plan for namespacing template funcs

Related topics