On Fri, Oct 19, 2018 at 7:13 AM Robert Engels <reng...@ix.netcom.com> wrote:
>
> I don’t think it matters, since when writing the generic code using methods
> the author has strict control over the precedence.
>
> Also, for equality testing, the signature would be bool Equals(interface{})
> with required casting. Without looking for flames, this is how Java does it
> and it’s never been a problem. You could go farther and define bool
> T.Equality(T) and have Equals defer to that when the type casts pass, or have
> the compiler perform the check and make the call.
>
> So I’m not sure of the problem.
I don't have strong opinions about operator overloading vs. using
methods for operators. The point of this thread was to offer an
alternative to contracts, and the alternative offered is still
valid with or without operator overloading.
Re: Ian Denhardt's proposal:
I agree that it handles all the cases in the official proposal,
but I think the syntax is too verbose and reminds me of
Java. For instance, the "sorting" example can be written using
the "like" keyword as:
Template:
type orderedSlice []like (int,string)
func (s orderedSlice) Len() int { return len(s) }
func (s orderedSlice) Less(i, j int) bool { return s[i]<s[j] }
func (s orderedSlice) Swap(i, j int) { s[i], s[j] = s[j], s[i] }
// There is no need for an OrderedSlice function
Concerete use:
type mySlice orderedSlice []int64
v:=mySlice{1,2,3}
sort.Slice(v)
However, one limitation of using interfaces to specify contracts
is that you can't use a struct type as a basis for your
contract. For instance, going back to the linked list example:
type Node like struct {
next *Node
}
With interfaces as contracts, this becomes:
type Node(type E) interface {
GetNext()
SetNext(*Node(E))
}
With this, you have to expose the internals of your linked list.
This is also related to the discussion about exposing private fields
of the template parameters. In the above case, we are not exposing
private fields of the template parameter, we are defining a template
with private fields which are used within the implementation of the
template. I don't think that breaks encapsulation, but the SetNext()
in the interface approach does.
>
> On Oct 19, 2018, at 7:59 AM, Lucio <lucio.d...@gmail.com> wrote:
>
> On Thursday, 18 October 2018 21:51:35 UTC+2, robert engels wrote:
>>
>> I guess I don’t understand the problem with using “method names” e.g. Less()
>> in generic code - yes it is a little more verbose - but it avoids the
>> traditional problems with operator overloading leading to obtuse code.
>>
> The issue that has not been raised yet, but is bound to come up, is that
> operators compose into expressions whereas methods have a much simpler, much
> more restrictive composition paradigm. Add operator precedence to the mix and
> stand well back.
>
> I frankly prefer methods to operators, but the need here is to retain the
> features of operators within generics and that means dealing with precedence
> as well as conversion, not just within the arithmetic realm, but specially
> across the operation, like when == transforms practically any compatible
> operands to a boolean result.
>
> Just adding my two cents of accelerant to a flammable mixture. Feel free to
> point out, if applicable, that I'm off topic and, specially instructive, why.
> But make it simple, there has been quite a bit written here I don't think
> I'll ever get my head around.
>
> Lucio.
>
> --
> 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.
>
> --
> 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.
--
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.
