As someone who learns by reviewing lots of existing projects, and standard 
libraries, and I review a lot of them, and so no I wouldn’t be an expert or 
author of these apis, IMO it is much harder to understand without the type 
information. 

I’ve seen similar results when you ask a person the review their own python 
code that they wrote more than 30 days ago... very hard to follow. 

Btw, the code is part of k8s. 

> On Nov 25, 2018, at 11:58 AM, Ian Denhardt <i...@zenhack.net> wrote:
> 
> 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.

-- 
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.

Reply via email to