Sorry for interfering. I've gathered statements and expressions which look
like candidates for interface-based generalization. Interface and method
names are just placeholders. Generic interfaces for collections like slice
or map are different beasts. Will post thoughts on them later.
I personally think that most used interface wrappers for predefined types
would be range support and generalized collections. Maybe custom key types
for maps and custom map hasher.
*Comparison operators*
"==", "!=", "<", ">", "<=", ">="
These can be split into two groups - equatable and ordered. Not all types
which may be compared equals can be ordered
type Equatable[T] interface {
Equals(T, T) bool
}
type Ordered[T] interface {
Compare(T, T) int // < 0 if less, > 0 if greater, 0 if equals
}
Equals can be easily implemented through Ordered via
func[T] (Ordered[T]* self) Equals(left, right T) bool {
return self.Compare(left right) == 0
}
Possible application for default interface methods but off-topic here
*Arithmetic operators*
*Unary operators "+", "-", "^"*
type UnaryOp[T] interface {
Op(T) T
}
where Op can be Plus, Minus, BitwiseComplement
*Binary operators "+", "-", "*", "/", "%", "&", "|", "^", "&^"*
type BinaryOp[T] interface {
Op(T, T) T
}
where Op is "Add", "Sub", "Mul", "Div", "Mod", "BitAnd", "BitOr", "BitXor",
"BitAndNot"
Bit-shift operators look almost the same except having different second
argument
type BinaryOp[T] interface {
Op(T, uint) T
}
where "Op" is "ShiftLeft" or "ShiftRight"
*Assign-op operators "+=", "-=", "*=", "/=", "%=", "&=", "|=", "^=", "&^="*
type BinaryOpAssign[T] interface {
OpAssign(T)
}
where Op is "Add", "Sub", "Mul", "Div", "Mod", "BitAnd", "BitOr", "BitXor",
"BitAndNot"
Default implementation through normal operation would look like
func[T] (BinaryOp[T]* self) OpAssign(right T) {
*self = self.Op(*self, right)
}
Except shift operators which would look like
type BinaryOpAssign[T] interface {
OpAssign(uint)
}
where "Op" is "ShiftLeft" or "ShiftRight"
*String concatenation*
Uses interfaces "BinaryAdd" and "BinaryAddAssign"
*Logical operators*
Applied only to booleans, so I see no good reason to add generic interfaces
for them
*Address operators*
Should not have their own interface since they don't assume any kind of
type-specific behavior
*Receive operator and send statement*
May be considered in future. ATM I don't see good application for
channel-like types except channels themselves
*Increment and decrement*
type Incrementable[T] interface {
Increment()
}
type Decrementable[T] interface {
Decrement()
}
*Assignment*
Not subject for generalization since it shouldn't be overridden
*For statements with range clause*
type Range[K, V] interface {
Next() K, V, bool
}
Slice's or string's key would be respective index
Channel looks more like exception here since it introduces asynchronous
iteration and produces single value.
On Saturday, August 15, 2020 at 3:14:30 PM UTC+3 rog wrote:
> On Sat, 15 Aug 2020 at 04:57, Patrick Smith <[email protected]> wrote:
>
>> On Thu, Aug 13, 2020 at 11:25 PM Patrick Smith <[email protected]>
>> wrote:
>> > I tried out a few different implementations, evaluating the polynomial
>> > instead of finding roots,
>> > at https://go2goplay.golang.org/p/g8bPHdg5iMd . As far as I can tell,
>> > there is no sensible way to
>> > do it with an interface that is implemented directly by *big.Float; we
>> > need to wrap *big.Float
>> > in a wrapper type in any case.
>>
>> After looking at the draft again, and seeing the Settable example
>> there, I realized we can do it using big.Float directly, but it needs
>> two interfaces, one matching big.Float and one matching *big.Float. I
>> have updated my examples at https://go2goplay.golang.org/p/auSkvhWSNHn
>
>
> I think that works pretty well, and seems to be the direction that things
> are going in.
> Here's your example cleaned up a bit to show just that latest example, and
> also
> showing how it looks when adapting a built-in type:
>
> https://go2goplay.golang.org/p/eFIvHocOC75
>
> It's possible to build a generic adaptor type from the value-style
> interface to the pointer-style interface, which you might find interesting:
>
> https://go2goplay.golang.org/p/NiQY_-kWvu8
>
> This could *almost* work on image.Point, except that Point.Mul has the
> wrong signature.
>
> cheers,
> rog.
>
>>
>> .
>
>
>>
>> --
>> 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 [email protected].
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAADvV_vxU7nUJ16X5xwBYhiOPVrzp%3DzrX%3DU4UTgBsOQJ2RnMuQ%40mail.gmail.com
>> .
>>
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/a5eb1222-d1f5-4f73-8ad7-5efc05f7a96bn%40googlegroups.com.
