Thanks for your comments, Ian.
Unfortunately, no approach is immune to silly mistakes by yours truly but,
as it's an area where "Effective Go" could offer some pointers, it need not
be unduly error prone in practice.
The problem with associating operators with named methods is that there
will be a lot of names for people to remember (or to list in the spec) and,
given that the built-ins don't have methods, it is unclear what mechanism
could be used to achieve this association.
With this approach you just have to write one additional method for any
type which you may need to sort and the standard operators will do the
rest. Using the 'official' draft design a contract for a sorting function
could be as simple as this:
contract ordered(x T) {
x < x
}
and would encompass not just the built-in ordered types (or types with such
an underlying type) but any other type with an OrderString() method.
I accept, of course, that efficiency may be a concern for large collections
given the relative slowness of string operations and generation of garbage.
However, you could always use a custom approach for these cases.
As you say the wiki feedback page could benefit from some organization
though, if Ian and Robert are planning a second draft in the not too
distinct future, a lot of the feedback may prove obsolete (or in need of
substantial revision) in any case.
Alan
On Saturday, October 13, 2018 at 7:14:10 PM UTC+1, Ian Denhardt wrote:
>
> Quoting alanfo (2018-10-13 13:26:18)
>
> > Suppose we turn this strategy on its head and instead allow types
> which
> > wouldn't otherwise do so support the ordering operators provided they
> > satisfy a simple interface. This interface would have a single method
> > which returned a string representation of an object of that type and
> > the compiler would use this string to implement the ordering
> operators.
> > which would enable us to do this:
> > p1 := Person{"Donald", 1, 20}� � // stringifies as Donald180
> > p2 := Person{"Donald", 2, 72}� � // stringifies as Donald128
> > b := p1 < p2� // false because p2 is older and therefore sorts first
>
> ..but you end up with `Person{"Donald", 3, 101}` < Person{"Donald", 2,
> 72}` being true, because the 101-year-old overflows the two digit space
> you've allocated.
>
> You can make this work by padding out to enough digits to be able to
> represent any `uint`, but this example suggests to me that the approach
> is likely to be error-prone in practice. My other immediate reaction is
> the efficiency concerns, which you bring up yourself.
>
> What is the advantage of the OrderString() approach over e.g. just
> having `x < y` desugar to `x.Less(y)` (if a method `Less` is defined on
> the type of x)? It is not clear to me what you suggest buys us over
> this.
>
> > I apologize if it's already been
> > suggested by someone else but I'm losing track of what has been
> > suggested in this area.
>
> ..it's probably getting to be time to add some organization to the wiki
> feedback page.
>
--
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.
