On Saturday, 3 November 2018 22:41:08 UTC+2, Andy Balholm wrote:
>
> I thought of a way to do something similar to the “implements” proposal
> without introducing operator overloading: turn it around. Instead of
> letting methods implement operators, we could let operators implement
> methods.
>
> There is something clever to that, I agree and largely like the idea,
specially its "outside the box" nature. Not that you should give much
weight to me liking it, my intuition is very poorly schooled.
That said, I can't resist suggesting that "method" needs to replace or
complement (parts of?) the "type interface" keyword combination, so it
looks different from what Go developers understand as the latter.
*What follows may well be off topic, I hope it stimulates further outside
the box thinking.*
And, what appeals to me the most, is that we are heading where I think
better minds than mine will eventually arrive: at a formal description of
operator properties such as "order" (vs "magnitude"); both of these so far
have been properties ("attributes", really: "property" itself is ambiguous)
of the "type", not of the operator.
Andy's proposal puts more emphasis where I believe it has to be. To me <
and its associates (but not ==) define "order" or "ordered", a property of
"ordinal", vs "cardinal", numbers and, in the computing environment, of
strings as well, and also, while I think about it, of the size (len) of
maps and slices.
This size thing, in particular, is special, as acknowledged in C by the
special definition of size_t as a different brand of integer (what does it
mean to "negate" - unary minus - the size of an array?).
I have no idea what the final conclusion is going to be of this discussion.
I think it leads towards the formal definition of certain properties of
intrinsic types that have not mattered until now, but need to become part
of the language. An optional part, as much as loops and conditionals were
optional in assembler, but essential at a higher level.
Does that mean that operator overloading (thinking of operators as mere
syntactic sugar) defines or requires a "higher level" programming notation
to describe and utilise them, again, the way loops added compile time
safety to undisciplined jumping around code?
type Lesser(type T) interface {
> Less(b T) bool for(<)
> }
>
> This interface would be implemented by any type that has an appropriate
> Less method, and by any type that works with the < operator. For example
> int would implement Lesser(int).
>
> It would be nice if we could get rid of the type parameter. One way would
> be to adopt the Self type from Rust:
>
> type Lesser interface {
> Less(b Self) bool for (<)
> }
>
> While trying to get my thoughts in some sort of shape, this question came
up: why is "type ... interface" not simply "interface ..."? Some rationale
applies and the only one I can think of is that "interface" then is not a
reserved word, except within the "type" namespace: I can have a variable or
function called "interface", but not a type.
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.
