FAQ
There are reasons against it:
http://gbracha.blogspot.de/2009/09/systemic-overload.html

-- Haddock

Am Mittwoch, 11. März 2015 19:35:08 UTC+1 schrieb Warren Bare:
I know you guys are cringing at the title. I've read a bunch of posts on
Go and function overloading, so before I ask the question, please let me
say:

1) I love Go and have used if for several year now (I'm not a hater).
2) I'm not asking about the intrinsic value of function overloading or if
it is needed (I just like overloading).
3) I have read the FAQ

So, here is the question: Why not? I still don't get it.

I feel like you compiler wonks can shed some light on this and make me
feel like there is more of a reason than "it's complicated" and "you'll
shoot your eye out."

*I'm talking specifically about compile time binding* just like the sort
of hidden overloading we already do (yes you heard me right... overloading
that we already do) for functions with various receivers. Specifically In
the section on defining methods on values or pointers, the FAQ says:

When defining a method on a type, the receiver (s in the above examples)
behaves exactly as if it were an argument to the method.


This is abstractly like thinking of 10 different Write() methods with 10
different receivers like 10 overloaded functions Write(Type1) Write(Type2)
Write(Type3).

I agree that we absolutely don't want to slow down runtime, but if the Go
definition of function/method overloading was that various signatures need
to be discreetly identifiable *at compile time *using the same basic
compile time signature checking we currently have, then why not?

The only argument that I have seen so far, which I do think some has
value, is simply "That is not the Go way." I totally get that. That is
the "you'll shoot your eye out" argument meaning... "just trust me, if you
want to do that, you are doing it wrong." The problem with this argument
is that the practice of overloading is so pervasive in the rest of the
language world, that people tend to not understand the Go way so they just
say, "Whatever... see you later... buh bye." Or, it is like telling
someone, "If you really want to overload, you are too stupid to use this
product." I'm joking here, but honestly, is lack of function/method
overloading really a core focus in Go?

More importantly, while I think focus (the Go way) is probably even more
important to success than most people realize, I'm just not convinced that
function overloading HURTS the Go way (so I don't ultimately buy that
particular argument), and I think it is clear from the forum posts that
lack of function overloading does turn people away from Go.

Ok, that's it. Rant finished. I will now submit willingly to my
reeducation. :-)

Thanks,
Warren
















--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 10 of 19 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMar 11, '15 at 6:35p
activeMar 12, '15 at 4:49p
posts19
users15
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase