In my opinion the interface represents the simplest way to allow operator
overloading. With an inbuilt interface that covers all the symbols and some
sort of category to break them down (boolean logic, binary logic,
arithmetic, misc unary, prefix infix and postfix). Then you can have the
built
Quoting Lucio (2018-09-21 16:15:19)
>The other thought I had, but is very poorly baked, is that the
>"essence" of polymorphism in Go operators is analogous to the informal
>definition of interfaces: it can be determined by the compiler, even
>though it is not expressed in a formal
I think the thing everyone who likes operator overloading like mainly is
being able to do infix and postfix syntax, instead of only prefix
(function). But then also what do you do about interfaces that also
implement an operator interface? I'd guess biggest reason to not do it is
1) no human r
On Saturday, 22 September 2018 16:47:00 UTC+2, Louki Sumirniy wrote:
>
> I think the thing everyone who likes operator overloading like mainly is
> being able to do infix and postfix syntax, instead of only prefix
> (function).
>
It's good that you brought that up, because another issue I rememb
the reason i wrote something like "...operator overloading, but wait, don't
get excited..." was to bring awareness of a core problem without
(hopefully) having people bring the burden of experience. i say burden
because bad experiences can shadow the 'why' that was good with the 'how'
that was bad.
> "I imagine I might be in the minority in using test this way. Its
useful when you have a small monorepo to do tests. People who run large
monorepos must have advanced tooling and individual modules won't notice
the behavior change."
Hi John,
Stepping back, one side question: how many
Hi Scott, all,
> "also I think they have obligated themselves to maintaining support
for the current functionality, which some might not
find fitting to the way they work."
Regarding the concern raised in that post -- I think it is definitely not
too late to give feedback on how modules work
I'm sorry, I've been meaning to reply. I'll do so tonight if I can.
--
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
Hello,
Is there a good active library that can serve HTML, CSS, and JS in a
desktop app without CGO? Something like electron for Go. I do not want to
programmatically create the GUI. I would rather create separate HTML. I
also do not need communication between the two, I can just run POST
requ
On Saturday, 22 September 2018 16:47:00 UTC+2, Louki Sumirniy wrote:
>
>I think the thing everyone who likes operator overloading like mainly
>is being able to do infix and postfix syntax, instead of only prefix
>(function).
My own reason for wanting this is not really about syntax, so
Issues like these highlight the deficiencies of Go compared to Java. The Java
designers understood languages far better, and from the start realized that
identity and reference equality were different concepts. Everyone in Go land
are debating these solved issues. Pick and chose what you want to
11 matches
Mail list logo
