On Tue, Oct 16, 2018 at 12:01 PM Ian Denhardt <i...@zenhack.net> wrote:
> * We don't actually need an adaptor for the zero value, since we can
> just declare a variable of the generic type:
>
> func MyFn(type T) {
> // x is the zero value, per usual initialization rules:
> var x T
>
True. This assumes that Go's usual initialization rules for type T produce
a value that will be interpreted as the additive identity for type T.
That's an assumption I would be happy to make.
But there are other values that could be useful and for which this
assumption doesn't hold. For example,
- One() (the multiplicative identity)
- MaxValue and MinValue() (extreme values for the type)
> One problem with this design, which bounding solves: Suppose we have a
> generic set type implemented using binary trees (I will use
> the 't notation discussed above, but you could use explicit parameter
> lists as well).
>
> type Order('t) interface{
> Less(x, y 't)
> }
>
> type Set('t) struct {
> // ...
> }
>
> func (s Set('t)) Insert('t; Order('t))
> func (s Set('t)) Member('t; Order('t)) bool
> // etc.
>
> What happens if we accidentally pass different adapters to different
> calls to the methods? e.g:
>
One way to avoid this is to supply the adaptor when the Set is created,
store it in the Set, and thereafter used the stored adaptor instead of
requiring an adaptor parameter.
type Set('t) struct {
o Order('t)
// ...
}
func MakeSet('t)(; o Order('t)) { var s Set('t); /* ... */; s.o = o; return
s }
func (s Set('t)) Insert('t)
func (s Set('t)) Member('t) bool
This presents a bit of a trade-off. Is it better to accept the overhead of
storing the adaptor, or to take the risk of having different adaptors
passed as parameters? The answer will depend on the situation.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
