Documentation
¶
Overview ¶
package main contains a Response to Stack Overflow question 71677581
Stack Overflow Post: https://stackoverflow.com/q/71677581
Go Playground version: https://go.dev/play/p/jR5MpX-Fopc
This repo: https://
Copyright (c) 2022 Michael Treanor ¶
MIT License ¶
GitHub: https://
Twitter: https://twitter.com/skeptycal
Index ¶
- func MyFuncAny(ex any) any
- func MyFuncInt(ex int) int
- func PrintFExample(m ExampleFuncMap)
- func PrintMapExample[K comparable, V any](m map[K]V)
- type AnyMap
- type ExampleFunc
- type ExampleFuncKeyMap
- type ExampleFuncMap
- type Exampler
- type ExamplerMap
- type FloatType
- type FuncMap
- type Funcer
- type IExample
- type IExampleBool
- type IExampleFloat
- type IExampleMap
- type IExampleMapAny
- type IExampleMapInt
- type IExampleMapTests
- type IntMap
- type IntType
- type Number
- type Ordered
- type StringMap
- type Test
- type TestMap
- type TestRunner
- type UintType
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func PrintFExample ¶
func PrintFExample(m ExampleFuncMap)
func PrintMapExample ¶
func PrintMapExample[K comparable, V any](m map[K]V)
PrintIExample actually can print any map, but is used here for the example type IExampleMap.
Types ¶
type AnyMap ¶
type AnyMap[K comparable, V any] map[K]V
AnyMap is an extremely generic definition, the map type can be defined in any possible combination of key and value types, so long as the 'key' type is comparable.
type ExampleFunc ¶
type ExampleFunc[T any] func(ex T) T
type based on function signature instead of interface implementation
type ExampleFuncKeyMap ¶
type ExampleFuncKeyMap[K comparable, V any] AnyMap[K, FuncMap[V]]
example of a function map with multiple types of keys and function argument allowed by the constraints
type ExampleFuncMap ¶
final type instantiated with 'any'
func CreateSampleFunctionMap ¶
func CreateSampleFunctionMap() ExampleFuncMap
CreateSampleFunctionMap returns an example map with several sample values.
type Exampler ¶
type Exampler[T any] interface { ExampleFunc(ex T) T }
It is getting somewhat cluttered ... perhaps it is more clear to define the interface first ...
type ExamplerMap ¶
This is probably the most clear and concise definition for the original map type: string keys, Exampler values, any type may be instantiated in the Exampler
type FloatType ¶
some useful constraints - incomplete, but good for example (e.g. leaves out complex numbers and uintptr, as well as ignoring structs, sequences, and sets that may be comparable based on their fields) as of this writing (4/01/22), the standard library 'constraints' package containing most of these constraints appears to be unavailable
type FuncMap ¶
type FuncMap[T any] StringMap[ExampleFunc[T]]
using a function signature as the value
type IExample ¶
type IExample[T any] interface { ExampleFunc(ex T) T }
The example in the question used a map with strings for keys and the IExample interface as the value type and the plan for the map was:
mapping := map[string]IExample[any]{
// .......
}
type IExampleBool ¶
type IExampleBool = ExamplerMap[bool]
types based on the original interface-based type
type IExampleFloat ¶
type IExampleFloat = ExamplerMap[float64]
a few other ExamplerMaps instantiated for various types as examples
type IExampleMap ¶
IExampleMap is a type I created for the entire map, instead of just the 'value' used in the original example. But ... is this the way to go? Is this clear and does it communicate the functionality?
type IExampleMapAny ¶
type IExampleMapAny = IExampleMap[any]
examples of IExampleMap instantiated for various types
func CreateSampleInterfaceMap ¶
func CreateSampleInterfaceMap() IExampleMapAny
CreateSampleInterfaceMap returns an example interface map with several sample values.
type IExampleMapInt ¶
type IExampleMapInt = IExampleMap[int]
types based on the original interface-based type
type IExampleMapTests ¶
type IExampleMapTests = IExampleMap[struct { name string fn interface{} in []interface{} want []interface{} wantErr bool }]
types based on the original interface-based type
type IntType ¶
some useful constraints - incomplete, but good for example (e.g. leaves out complex numbers and uintptr, as well as ignoring structs, sequences, and sets that may be comparable based on their fields) as of this writing (4/01/22), the standard library 'constraints' package containing most of these constraints appears to be unavailable
type Number ¶
some useful constraints - incomplete, but good for example (e.g. leaves out complex numbers and uintptr, as well as ignoring structs, sequences, and sets that may be comparable based on their fields) as of this writing (4/01/22), the standard library 'constraints' package containing most of these constraints appears to be unavailable
type Ordered ¶
some useful constraints - incomplete, but good for example (e.g. leaves out complex numbers and uintptr, as well as ignoring structs, sequences, and sets that may be comparable based on their fields) as of this writing (4/01/22), the standard library 'constraints' package containing most of these constraints appears to be unavailable
type Test ¶
type Test[O Ordered] struct { // contains filtered or unexported fields }
Perhaps ... a useful set of defintions for running generic table-based tests.
type TestMap ¶
type TestMap[K comparable, V Ordered] AnyMap[K, Test[V]]
TestMap is a map of table-based test objects
type TestRunner ¶
Perhaps ... a useful set of defintions for running generic table-based tests.
type UintType ¶
some useful constraints - incomplete, but good for example (e.g. leaves out complex numbers and uintptr, as well as ignoring structs, sequences, and sets that may be comparable based on their fields) as of this writing (4/01/22), the standard library 'constraints' package containing most of these constraints appears to be unavailable