On Tuesday, 8 August 2017 09:06:08 UTC+2, marti...@programmfabrik.de wrote:
>
> [...] So why not come up with
>
> func findFirst(slice interface{}, matches func(i int
> <https://golang.org/pkg/builtin/#int>) bool
> <https://golang.org/pkg/builtin/#bool>)
>
> or so?
>
Well, this looks harmless but the major work is not in iterating the slice
but in handling all the subtle cases in match. E.g. in numerical code
the NaNs, the +/-Infs, the values just formally != 0 (but too small for
general computations). For strings the various Unicode normalisation
forms, BOMs, etc. For objects without simple value semantics like
streams, channel or network connections where matching them might
change their state and might no be easily undoable.
So if match is simple like func(i int){ s[i].Id == 7 } then the proposed
findFirst function saves 2 or three lines of code. Code almost any
team gets right on the first try in 10 minutes.
But if the match is non-trivial then the 2 lines saved is not a game
changer.
So why bother?
One more point: There might be no match in the slice so this findFirst
would have to return -1 to indicate "not found". If this can happen your
code would have to handle this as well; which makes the ratio of
"lines you have to write to cover the business logic" to "lines saved
by having a generic findFirst" even bigger.
(Of course one could go down the function proliferation road and add a
mustFindFirst...)
V.
--
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.
