i think the lack of implicit casts makes the idea much better in Go.
I was just thinking of my admiration for goimport sand how nicely that
enriches he programming practice.
if the argument-distinguished function names have the same base name
("MakeCircle$" where $ is one of PointRadius, ThreePoi
On Sunday, 9 September 2018 15:54:34 UTC+2, Michael Jones wrote:
>
>
> On the down side, if things go wrong, you don't know what source code to
> go look at. I admit being confused before (C++) as to which overloaded
> function/method was being called because of default type casts. That is
> f
I think that is a small matter, and the compiler could easily prevent these
overlapping method signatures. I think you rarely have that anyway in well
designed code, because you don’t need the single parameter version, as the
multiple parameter version also covers the single parameter case, but
On September 9, 2018 1:43:09 PM UTC, robert engels
wrote:
>I think the lack of method overload is a poor choice.
>
> …
>
>I would much rather write
>
>NewCircle([]Point)
>NewCircle(center Point,radius int)
>
>than
>
>NewCircleFromPoints
>NewCircleFromCenterWithRadius
>
>and this is just a very
I don’t see how that works - the details struct would need to be very complex,
and the NewCircle would need to figure out which method the caller is intended
(e.g. is the points nil, then the user must want to do center and radius) -
very error prone too IWT.
> On Sep 9, 2018, at 8:54 AM, Micha
It is a good example of good and bad.
NewCircle(details)
is conceptually optimal. Everyone knows what is intended, and it is easier
to type.
On the down side, if things go wrong, you don't know what source code to go
look at. I admit being confused before (C++) as to which overloaded
function/me
I think the lack of method overload is a poor choice. A simple review of the
stdlib shows a lot of XFromInt XFromUnit and that is workable, but when you
have complex structs as parameters, then the naming because really long… and
the fact that you don’t have file level hiding, means even for loc
On Sat, Sep 8, 2018 at 6:58 PM, Rick
wrote:
[ replacing "operator" by "method" since that seems to be what was intended ]
> Is support for [method] overloading implied by support for generics?
No.
> Is it > possible to have one with the other?
Yes, they are entirely independent.
> To be hone
I believe what you're discussing in this case is function or method
overloading. Operator overloading refers to the ability to specify custom
behavior for operators like +, -, etc.
On Sat, Sep 8, 2018 at 6:58 PM Rick
wrote:
> With recent discussion concerning the possible introduction of generic
With recent discussion concerning the possible introduction of generics in
Go 2, it occurs to me to ask about support for operator overloading in Go
2. By this I mean support for functions having the same name but different
signature:
func foo(x int) int ...
func foo(x string) bool ...
func f
10 matches
Mail list logo
