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/method was being called because of default type casts. That is frustrating and can easily be a source of error. One half-way approach would be tooling. Imasine an editor that, like auto imports was able to auto disambiguate in just these cases. On Sun, Sep 9, 2018 at 6:43 AM robert engels <reng...@ix.netcom.com> wrote: > 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 > local structures this is a problem across the package. > > I would much rather write > > NewCircle([]Point) > NewCircle(center Point,radius int) > > than > > NewCircleFromPoints > NewCircleFromCenterWithRadius > > and this is just a very simple example. > > > On Sep 9, 2018, at 7:45 AM, Ian Lance Taylor <i...@golang.org> wrote: > > > > On Sat, Sep 8, 2018 at 6:58 PM, Rick > > <thesuggestednamesareaw...@gmail.com> 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 honest, I've been more bothered > >> by the lack of [method] overloading than by the absence of generics. > And (I > >> assume) no new syntax would be required to support overloading. Or would > >> there? > > > > I don't think any new syntax would be required. But there is no > > serious proposal on the table for method overloading, and the language > > made an explicit decision on the matter early on: > > https://golang.org/doc/faq#overloading . Not that we could never > > change it, but it would need a very strong argument. > > > > Ian > > > > -- > > 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. > > -- > 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. > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- 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.
