Quoting robert engels (2018-11-25 01:39:30)
> You kind of made my point, when you state “it’s either a slice or a
> map”… Well, what if the resource needed to be ordered, which is why the
> previous method has List in its name, but the method was actually
> returning a map.
If the authors of meta.ExtractList made this design mistake, why would
we expect them not to have done the same thing when declaring a wrapper
type? e.g.
type List map[string]Resource
I'll point again to this snipped from my last email:
> > if I'm not already familiar with the APIs involved (which I'm not),
> > changing it to e.g:
> >
> > var objList ResourceList
> > objList, err := ...
> >
> > Does not give me any additional insight.
> Yes, someone should of caught that in the code review for the
> extractList method, but if someone didn’t, the error is being compounded
> here, with no obvious way to detect that during a code review…
If I find myself forgetting/misunderstanding bits of an API that I have
control over when reviewing places where it's used, I should go fix the
API.
There is simply no substitute for this. Optimizing for the case where
you're already building on a house of cards is a fools errand.
This really reads like a case of "new feature is scary, let's put
caution tape all over it" that you see people making the case for any
time anyone adds a new feature to a language. I think this is more about
what you're used to than what actually makes for readable code.
--
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.
