2017-01-25 08:13:02 +05:30
|
|
|
// Copyright 2017 The Gitea Authors. All rights reserved.
|
2022-11-27 23:50:29 +05:30
|
|
|
// SPDX-License-Identifier: MIT
|
2017-01-25 08:13:02 +05:30
|
|
|
|
|
|
|
package util
|
|
|
|
|
2018-02-20 18:20:42 +05:30
|
|
|
import (
|
2019-11-13 07:57:11 +05:30
|
|
|
"bytes"
|
2021-05-10 12:15:17 +05:30
|
|
|
"crypto/rand"
|
2020-11-25 16:50:40 +05:30
|
|
|
"errors"
|
2023-04-03 22:28:09 +05:30
|
|
|
"fmt"
|
2021-05-10 12:15:17 +05:30
|
|
|
"math/big"
|
2021-10-12 23:41:35 +05:30
|
|
|
"strconv"
|
2018-05-29 09:21:42 +05:30
|
|
|
"strings"
|
2022-05-11 03:25:54 +05:30
|
|
|
|
|
|
|
"golang.org/x/text/cases"
|
|
|
|
"golang.org/x/text/language"
|
2018-02-20 18:20:42 +05:30
|
|
|
)
|
|
|
|
|
2017-01-25 08:13:02 +05:30
|
|
|
// OptionalBool a boolean that can be "null"
|
|
|
|
type OptionalBool byte
|
|
|
|
|
|
|
|
const (
|
|
|
|
// OptionalBoolNone a "null" boolean value
|
2021-10-12 23:41:35 +05:30
|
|
|
OptionalBoolNone OptionalBool = iota
|
2017-01-25 08:13:02 +05:30
|
|
|
// OptionalBoolTrue a "true" boolean value
|
|
|
|
OptionalBoolTrue
|
|
|
|
// OptionalBoolFalse a "false" boolean value
|
|
|
|
OptionalBoolFalse
|
|
|
|
)
|
|
|
|
|
2017-10-24 23:06:19 +05:30
|
|
|
// IsTrue return true if equal to OptionalBoolTrue
|
|
|
|
func (o OptionalBool) IsTrue() bool {
|
|
|
|
return o == OptionalBoolTrue
|
|
|
|
}
|
|
|
|
|
|
|
|
// IsFalse return true if equal to OptionalBoolFalse
|
|
|
|
func (o OptionalBool) IsFalse() bool {
|
|
|
|
return o == OptionalBoolFalse
|
|
|
|
}
|
|
|
|
|
|
|
|
// IsNone return true if equal to OptionalBoolNone
|
|
|
|
func (o OptionalBool) IsNone() bool {
|
|
|
|
return o == OptionalBoolNone
|
|
|
|
}
|
|
|
|
|
2017-01-25 08:13:02 +05:30
|
|
|
// OptionalBoolOf get the corresponding OptionalBool of a bool
|
|
|
|
func OptionalBoolOf(b bool) OptionalBool {
|
|
|
|
if b {
|
|
|
|
return OptionalBoolTrue
|
|
|
|
}
|
|
|
|
return OptionalBoolFalse
|
|
|
|
}
|
2017-10-27 11:40:54 +05:30
|
|
|
|
2021-10-12 23:41:35 +05:30
|
|
|
// OptionalBoolParse get the corresponding OptionalBool of a string using strconv.ParseBool
|
|
|
|
func OptionalBoolParse(s string) OptionalBool {
|
|
|
|
b, e := strconv.ParseBool(s)
|
|
|
|
if e != nil {
|
|
|
|
return OptionalBoolNone
|
|
|
|
}
|
|
|
|
return OptionalBoolOf(b)
|
|
|
|
}
|
|
|
|
|
2017-10-27 11:40:54 +05:30
|
|
|
// Max max of two ints
|
|
|
|
func Max(a, b int) int {
|
|
|
|
if a < b {
|
|
|
|
return b
|
|
|
|
}
|
|
|
|
return a
|
|
|
|
}
|
|
|
|
|
|
|
|
// Min min of two ints
|
|
|
|
func Min(a, b int) int {
|
|
|
|
if a > b {
|
|
|
|
return b
|
|
|
|
}
|
|
|
|
return a
|
|
|
|
}
|
2019-01-21 17:15:32 +05:30
|
|
|
|
|
|
|
// IsEmptyString checks if the provided string is empty
|
|
|
|
func IsEmptyString(s string) bool {
|
|
|
|
return len(strings.TrimSpace(s)) == 0
|
|
|
|
}
|
2019-11-13 07:57:11 +05:30
|
|
|
|
|
|
|
// NormalizeEOL will convert Windows (CRLF) and Mac (CR) EOLs to UNIX (LF)
|
|
|
|
func NormalizeEOL(input []byte) []byte {
|
|
|
|
var right, left, pos int
|
|
|
|
if right = bytes.IndexByte(input, '\r'); right == -1 {
|
|
|
|
return input
|
|
|
|
}
|
|
|
|
length := len(input)
|
|
|
|
tmp := make([]byte, length)
|
|
|
|
|
|
|
|
// We know that left < length because otherwise right would be -1 from IndexByte.
|
|
|
|
copy(tmp[pos:pos+right], input[left:left+right])
|
|
|
|
pos += right
|
|
|
|
tmp[pos] = '\n'
|
|
|
|
left += right + 1
|
|
|
|
pos++
|
|
|
|
|
|
|
|
for left < length {
|
|
|
|
if input[left] == '\n' {
|
|
|
|
left++
|
|
|
|
}
|
|
|
|
|
|
|
|
right = bytes.IndexByte(input[left:], '\r')
|
|
|
|
if right == -1 {
|
|
|
|
copy(tmp[pos:], input[left:])
|
|
|
|
pos += length - left
|
|
|
|
break
|
|
|
|
}
|
|
|
|
copy(tmp[pos:pos+right], input[left:left+right])
|
|
|
|
pos += right
|
|
|
|
tmp[pos] = '\n'
|
|
|
|
left += right + 1
|
|
|
|
pos++
|
|
|
|
}
|
|
|
|
return tmp[:pos]
|
|
|
|
}
|
2020-11-25 16:50:40 +05:30
|
|
|
|
|
|
|
// MergeInto merges pairs of values into a "dict"
|
|
|
|
func MergeInto(dict map[string]interface{}, values ...interface{}) (map[string]interface{}, error) {
|
|
|
|
for i := 0; i < len(values); i++ {
|
|
|
|
switch key := values[i].(type) {
|
|
|
|
case string:
|
|
|
|
i++
|
|
|
|
if i == len(values) {
|
|
|
|
return nil, errors.New("specify the key for non array values")
|
|
|
|
}
|
|
|
|
dict[key] = values[i]
|
|
|
|
case map[string]interface{}:
|
|
|
|
m := values[i].(map[string]interface{})
|
|
|
|
for i, v := range m {
|
|
|
|
dict[i] = v
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
return nil, errors.New("dict values must be maps")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return dict, nil
|
|
|
|
}
|
2021-05-10 12:15:17 +05:30
|
|
|
|
2022-01-26 09:40:10 +05:30
|
|
|
// CryptoRandomInt returns a crypto random integer between 0 and limit, inclusive
|
|
|
|
func CryptoRandomInt(limit int64) (int64, error) {
|
2022-01-04 20:43:52 +05:30
|
|
|
rInt, err := rand.Int(rand.Reader, big.NewInt(limit))
|
2021-05-10 12:15:17 +05:30
|
|
|
if err != nil {
|
|
|
|
return 0, err
|
|
|
|
}
|
2022-01-04 20:43:52 +05:30
|
|
|
return rInt.Int64(), nil
|
2021-05-10 12:15:17 +05:30
|
|
|
}
|
|
|
|
|
2022-01-26 09:40:10 +05:30
|
|
|
const alphanumericalChars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"
|
2021-05-10 12:15:17 +05:30
|
|
|
|
2022-01-26 09:40:10 +05:30
|
|
|
// CryptoRandomString generates a crypto random alphanumerical string, each byte is generated by [0,61] range
|
|
|
|
func CryptoRandomString(length int64) (string, error) {
|
|
|
|
buf := make([]byte, length)
|
|
|
|
limit := int64(len(alphanumericalChars))
|
|
|
|
for i := range buf {
|
|
|
|
num, err := CryptoRandomInt(limit)
|
2021-05-10 12:15:17 +05:30
|
|
|
if err != nil {
|
|
|
|
return "", err
|
|
|
|
}
|
2022-01-26 09:40:10 +05:30
|
|
|
buf[i] = alphanumericalChars[num]
|
2021-05-10 12:15:17 +05:30
|
|
|
}
|
2022-01-26 09:40:10 +05:30
|
|
|
return string(buf), nil
|
2021-05-10 12:15:17 +05:30
|
|
|
}
|
2022-01-04 20:43:52 +05:30
|
|
|
|
2022-01-26 09:40:10 +05:30
|
|
|
// CryptoRandomBytes generates `length` crypto bytes
|
|
|
|
// This differs from CryptoRandomString, as each byte in CryptoRandomString is generated by [0,61] range
|
|
|
|
// This function generates totally random bytes, each byte is generated by [0,255] range
|
|
|
|
func CryptoRandomBytes(length int64) ([]byte, error) {
|
|
|
|
buf := make([]byte, length)
|
|
|
|
_, err := rand.Read(buf)
|
|
|
|
return buf, err
|
2022-01-04 20:43:52 +05:30
|
|
|
}
|
2022-02-01 18:29:25 +05:30
|
|
|
|
|
|
|
// ToUpperASCII returns s with all ASCII letters mapped to their upper case.
|
|
|
|
func ToUpperASCII(s string) string {
|
|
|
|
b := []byte(s)
|
|
|
|
for i, c := range b {
|
|
|
|
if 'a' <= c && c <= 'z' {
|
|
|
|
b[i] -= 'a' - 'A'
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return string(b)
|
|
|
|
}
|
2022-05-11 03:25:54 +05:30
|
|
|
|
|
|
|
// ToTitleCase returns s with all english words capitalized
|
|
|
|
func ToTitleCase(s string) string {
|
2023-04-04 03:33:45 +05:30
|
|
|
// `cases.Title` is not thread-safe, do not use global shared variable for it
|
|
|
|
return cases.Title(language.English).String(s)
|
2022-05-11 03:25:54 +05:30
|
|
|
}
|
2022-06-10 19:15:28 +05:30
|
|
|
|
2023-04-04 03:33:45 +05:30
|
|
|
// ToTitleCaseNoLower returns s with all english words capitalized without lower-casing
|
2022-11-19 16:38:06 +05:30
|
|
|
func ToTitleCaseNoLower(s string) string {
|
2023-04-04 03:33:45 +05:30
|
|
|
// `cases.Title` is not thread-safe, do not use global shared variable for it
|
|
|
|
return cases.Title(language.English, cases.NoLower).String(s)
|
2022-11-19 16:38:06 +05:30
|
|
|
}
|
|
|
|
|
2023-04-03 22:28:09 +05:30
|
|
|
// ToInt64 transform a given int into int64.
|
Use a general Eval function for expressions in templates. (#23927)
One of the proposals in #23328
This PR introduces a simple expression calculator
(templates/eval/eval.go), it can do basic expression calculations.
Many untested template helper functions like `Mul` `Add` can be replaced
by this new approach.
Then these `Add` / `Mul` / `percentage` / `Subtract` / `DiffStatsWidth`
could all use this `Eval`.
And it provides enhancements for Golang templates, and improves
readability.
Some examples:
----
* Before: `{{Add (Mul $glyph.Row 12) 12}}`
* After: `{{Eval $glyph.Row "*" 12 "+" 12}}`
----
* Before: `{{if lt (Add $i 1) (len $.Topics)}}`
* After: `{{if Eval $i "+" 1 "<" (len $.Topics)}}`
## FAQ
### Why not use an existing expression package?
We need a highly customized expression engine:
* do the calculation on the fly, without pre-compiling
* deal with int/int64/float64 types, to make the result could be used in
Golang template.
* make the syntax could be used in the Golang template directly
* do not introduce too much complex or strange syntax, we just need a
simple calculator.
* it needs to strictly follow Golang template's behavior, for example,
Golang template treats all non-zero values as truth, but many 3rd
packages don't do so.
### What's the benefit?
* Developers don't need to add more `Add`/`Mul`/`Sub`-like functions,
they were getting more and more.
Now, only one `Eval` is enough for all cases.
* The new code reads better than old `{{Add (Mul $glyph.Row 12) 12}}`,
the old one isn't familiar to most procedural programming developers
(eg, the Golang expression syntax).
* The `Eval` is fully covered by tests, many old `Add`/`Mul`-like
functions were never tested.
### The performance?
It doesn't use `reflect`, it doesn't need to parse or compile when used
in Golang template, the performance is as fast as native Go template.
### Is it too complex? Could it be unstable?
The expression calculator program is a common homework for computer
science students, and it's widely used as a teaching and practicing
purpose for developers. The algorithm is pretty well-known.
The behavior can be clearly defined, it is stable.
2023-04-07 18:55:49 +05:30
|
|
|
func ToInt64(number interface{}) (int64, error) {
|
2022-06-12 17:38:23 +05:30
|
|
|
var value int64
|
|
|
|
switch v := number.(type) {
|
|
|
|
case int:
|
|
|
|
value = int64(v)
|
|
|
|
case int8:
|
|
|
|
value = int64(v)
|
|
|
|
case int16:
|
|
|
|
value = int64(v)
|
|
|
|
case int32:
|
|
|
|
value = int64(v)
|
|
|
|
case int64:
|
|
|
|
value = v
|
Use a general Eval function for expressions in templates. (#23927)
One of the proposals in #23328
This PR introduces a simple expression calculator
(templates/eval/eval.go), it can do basic expression calculations.
Many untested template helper functions like `Mul` `Add` can be replaced
by this new approach.
Then these `Add` / `Mul` / `percentage` / `Subtract` / `DiffStatsWidth`
could all use this `Eval`.
And it provides enhancements for Golang templates, and improves
readability.
Some examples:
----
* Before: `{{Add (Mul $glyph.Row 12) 12}}`
* After: `{{Eval $glyph.Row "*" 12 "+" 12}}`
----
* Before: `{{if lt (Add $i 1) (len $.Topics)}}`
* After: `{{if Eval $i "+" 1 "<" (len $.Topics)}}`
## FAQ
### Why not use an existing expression package?
We need a highly customized expression engine:
* do the calculation on the fly, without pre-compiling
* deal with int/int64/float64 types, to make the result could be used in
Golang template.
* make the syntax could be used in the Golang template directly
* do not introduce too much complex or strange syntax, we just need a
simple calculator.
* it needs to strictly follow Golang template's behavior, for example,
Golang template treats all non-zero values as truth, but many 3rd
packages don't do so.
### What's the benefit?
* Developers don't need to add more `Add`/`Mul`/`Sub`-like functions,
they were getting more and more.
Now, only one `Eval` is enough for all cases.
* The new code reads better than old `{{Add (Mul $glyph.Row 12) 12}}`,
the old one isn't familiar to most procedural programming developers
(eg, the Golang expression syntax).
* The `Eval` is fully covered by tests, many old `Add`/`Mul`-like
functions were never tested.
### The performance?
It doesn't use `reflect`, it doesn't need to parse or compile when used
in Golang template, the performance is as fast as native Go template.
### Is it too complex? Could it be unstable?
The expression calculator program is a common homework for computer
science students, and it's widely used as a teaching and practicing
purpose for developers. The algorithm is pretty well-known.
The behavior can be clearly defined, it is stable.
2023-04-07 18:55:49 +05:30
|
|
|
|
2023-04-03 22:28:09 +05:30
|
|
|
case uint:
|
|
|
|
value = int64(v)
|
|
|
|
case uint8:
|
|
|
|
value = int64(v)
|
|
|
|
case uint16:
|
|
|
|
value = int64(v)
|
|
|
|
case uint32:
|
|
|
|
value = int64(v)
|
|
|
|
case uint64:
|
|
|
|
value = int64(v)
|
Use a general Eval function for expressions in templates. (#23927)
One of the proposals in #23328
This PR introduces a simple expression calculator
(templates/eval/eval.go), it can do basic expression calculations.
Many untested template helper functions like `Mul` `Add` can be replaced
by this new approach.
Then these `Add` / `Mul` / `percentage` / `Subtract` / `DiffStatsWidth`
could all use this `Eval`.
And it provides enhancements for Golang templates, and improves
readability.
Some examples:
----
* Before: `{{Add (Mul $glyph.Row 12) 12}}`
* After: `{{Eval $glyph.Row "*" 12 "+" 12}}`
----
* Before: `{{if lt (Add $i 1) (len $.Topics)}}`
* After: `{{if Eval $i "+" 1 "<" (len $.Topics)}}`
## FAQ
### Why not use an existing expression package?
We need a highly customized expression engine:
* do the calculation on the fly, without pre-compiling
* deal with int/int64/float64 types, to make the result could be used in
Golang template.
* make the syntax could be used in the Golang template directly
* do not introduce too much complex or strange syntax, we just need a
simple calculator.
* it needs to strictly follow Golang template's behavior, for example,
Golang template treats all non-zero values as truth, but many 3rd
packages don't do so.
### What's the benefit?
* Developers don't need to add more `Add`/`Mul`/`Sub`-like functions,
they were getting more and more.
Now, only one `Eval` is enough for all cases.
* The new code reads better than old `{{Add (Mul $glyph.Row 12) 12}}`,
the old one isn't familiar to most procedural programming developers
(eg, the Golang expression syntax).
* The `Eval` is fully covered by tests, many old `Add`/`Mul`-like
functions were never tested.
### The performance?
It doesn't use `reflect`, it doesn't need to parse or compile when used
in Golang template, the performance is as fast as native Go template.
### Is it too complex? Could it be unstable?
The expression calculator program is a common homework for computer
science students, and it's widely used as a teaching and practicing
purpose for developers. The algorithm is pretty well-known.
The behavior can be clearly defined, it is stable.
2023-04-07 18:55:49 +05:30
|
|
|
|
|
|
|
case float32:
|
|
|
|
value = int64(v)
|
|
|
|
case float64:
|
|
|
|
value = int64(v)
|
|
|
|
|
2023-04-03 22:28:09 +05:30
|
|
|
case string:
|
|
|
|
var err error
|
|
|
|
if value, err = strconv.ParseInt(v, 10, 64); err != nil {
|
Use a general Eval function for expressions in templates. (#23927)
One of the proposals in #23328
This PR introduces a simple expression calculator
(templates/eval/eval.go), it can do basic expression calculations.
Many untested template helper functions like `Mul` `Add` can be replaced
by this new approach.
Then these `Add` / `Mul` / `percentage` / `Subtract` / `DiffStatsWidth`
could all use this `Eval`.
And it provides enhancements for Golang templates, and improves
readability.
Some examples:
----
* Before: `{{Add (Mul $glyph.Row 12) 12}}`
* After: `{{Eval $glyph.Row "*" 12 "+" 12}}`
----
* Before: `{{if lt (Add $i 1) (len $.Topics)}}`
* After: `{{if Eval $i "+" 1 "<" (len $.Topics)}}`
## FAQ
### Why not use an existing expression package?
We need a highly customized expression engine:
* do the calculation on the fly, without pre-compiling
* deal with int/int64/float64 types, to make the result could be used in
Golang template.
* make the syntax could be used in the Golang template directly
* do not introduce too much complex or strange syntax, we just need a
simple calculator.
* it needs to strictly follow Golang template's behavior, for example,
Golang template treats all non-zero values as truth, but many 3rd
packages don't do so.
### What's the benefit?
* Developers don't need to add more `Add`/`Mul`/`Sub`-like functions,
they were getting more and more.
Now, only one `Eval` is enough for all cases.
* The new code reads better than old `{{Add (Mul $glyph.Row 12) 12}}`,
the old one isn't familiar to most procedural programming developers
(eg, the Golang expression syntax).
* The `Eval` is fully covered by tests, many old `Add`/`Mul`-like
functions were never tested.
### The performance?
It doesn't use `reflect`, it doesn't need to parse or compile when used
in Golang template, the performance is as fast as native Go template.
### Is it too complex? Could it be unstable?
The expression calculator program is a common homework for computer
science students, and it's widely used as a teaching and practicing
purpose for developers. The algorithm is pretty well-known.
The behavior can be clearly defined, it is stable.
2023-04-07 18:55:49 +05:30
|
|
|
return 0, err
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
return 0, fmt.Errorf("unable to convert %v to int64", number)
|
|
|
|
}
|
|
|
|
return value, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// ToFloat64 transform a given int into float64.
|
|
|
|
func ToFloat64(number interface{}) (float64, error) {
|
|
|
|
var value float64
|
|
|
|
switch v := number.(type) {
|
|
|
|
case int:
|
|
|
|
value = float64(v)
|
|
|
|
case int8:
|
|
|
|
value = float64(v)
|
|
|
|
case int16:
|
|
|
|
value = float64(v)
|
|
|
|
case int32:
|
|
|
|
value = float64(v)
|
|
|
|
case int64:
|
|
|
|
value = float64(v)
|
|
|
|
|
|
|
|
case uint:
|
|
|
|
value = float64(v)
|
|
|
|
case uint8:
|
|
|
|
value = float64(v)
|
|
|
|
case uint16:
|
|
|
|
value = float64(v)
|
|
|
|
case uint32:
|
|
|
|
value = float64(v)
|
|
|
|
case uint64:
|
|
|
|
value = float64(v)
|
|
|
|
|
|
|
|
case float32:
|
|
|
|
value = float64(v)
|
|
|
|
case float64:
|
|
|
|
value = v
|
|
|
|
|
|
|
|
case string:
|
|
|
|
var err error
|
|
|
|
if value, err = strconv.ParseFloat(v, 64); err != nil {
|
|
|
|
return 0, err
|
2023-04-03 22:28:09 +05:30
|
|
|
}
|
|
|
|
default:
|
Use a general Eval function for expressions in templates. (#23927)
One of the proposals in #23328
This PR introduces a simple expression calculator
(templates/eval/eval.go), it can do basic expression calculations.
Many untested template helper functions like `Mul` `Add` can be replaced
by this new approach.
Then these `Add` / `Mul` / `percentage` / `Subtract` / `DiffStatsWidth`
could all use this `Eval`.
And it provides enhancements for Golang templates, and improves
readability.
Some examples:
----
* Before: `{{Add (Mul $glyph.Row 12) 12}}`
* After: `{{Eval $glyph.Row "*" 12 "+" 12}}`
----
* Before: `{{if lt (Add $i 1) (len $.Topics)}}`
* After: `{{if Eval $i "+" 1 "<" (len $.Topics)}}`
## FAQ
### Why not use an existing expression package?
We need a highly customized expression engine:
* do the calculation on the fly, without pre-compiling
* deal with int/int64/float64 types, to make the result could be used in
Golang template.
* make the syntax could be used in the Golang template directly
* do not introduce too much complex or strange syntax, we just need a
simple calculator.
* it needs to strictly follow Golang template's behavior, for example,
Golang template treats all non-zero values as truth, but many 3rd
packages don't do so.
### What's the benefit?
* Developers don't need to add more `Add`/`Mul`/`Sub`-like functions,
they were getting more and more.
Now, only one `Eval` is enough for all cases.
* The new code reads better than old `{{Add (Mul $glyph.Row 12) 12}}`,
the old one isn't familiar to most procedural programming developers
(eg, the Golang expression syntax).
* The `Eval` is fully covered by tests, many old `Add`/`Mul`-like
functions were never tested.
### The performance?
It doesn't use `reflect`, it doesn't need to parse or compile when used
in Golang template, the performance is as fast as native Go template.
### Is it too complex? Could it be unstable?
The expression calculator program is a common homework for computer
science students, and it's widely used as a teaching and practicing
purpose for developers. The algorithm is pretty well-known.
The behavior can be clearly defined, it is stable.
2023-04-07 18:55:49 +05:30
|
|
|
return 0, fmt.Errorf("unable to convert %v to float64", number)
|
2022-06-12 17:38:23 +05:30
|
|
|
}
|
Use a general Eval function for expressions in templates. (#23927)
One of the proposals in #23328
This PR introduces a simple expression calculator
(templates/eval/eval.go), it can do basic expression calculations.
Many untested template helper functions like `Mul` `Add` can be replaced
by this new approach.
Then these `Add` / `Mul` / `percentage` / `Subtract` / `DiffStatsWidth`
could all use this `Eval`.
And it provides enhancements for Golang templates, and improves
readability.
Some examples:
----
* Before: `{{Add (Mul $glyph.Row 12) 12}}`
* After: `{{Eval $glyph.Row "*" 12 "+" 12}}`
----
* Before: `{{if lt (Add $i 1) (len $.Topics)}}`
* After: `{{if Eval $i "+" 1 "<" (len $.Topics)}}`
## FAQ
### Why not use an existing expression package?
We need a highly customized expression engine:
* do the calculation on the fly, without pre-compiling
* deal with int/int64/float64 types, to make the result could be used in
Golang template.
* make the syntax could be used in the Golang template directly
* do not introduce too much complex or strange syntax, we just need a
simple calculator.
* it needs to strictly follow Golang template's behavior, for example,
Golang template treats all non-zero values as truth, but many 3rd
packages don't do so.
### What's the benefit?
* Developers don't need to add more `Add`/`Mul`/`Sub`-like functions,
they were getting more and more.
Now, only one `Eval` is enough for all cases.
* The new code reads better than old `{{Add (Mul $glyph.Row 12) 12}}`,
the old one isn't familiar to most procedural programming developers
(eg, the Golang expression syntax).
* The `Eval` is fully covered by tests, many old `Add`/`Mul`-like
functions were never tested.
### The performance?
It doesn't use `reflect`, it doesn't need to parse or compile when used
in Golang template, the performance is as fast as native Go template.
### Is it too complex? Could it be unstable?
The expression calculator program is a common homework for computer
science students, and it's widely used as a teaching and practicing
purpose for developers. The algorithm is pretty well-known.
The behavior can be clearly defined, it is stable.
2023-04-07 18:55:49 +05:30
|
|
|
return value, nil
|
2022-06-12 17:38:23 +05:30
|
|
|
}
|