I feel much better with this,
than its counter part,
but what s the point, this is so much about a personal opinion.
func (p PackageInfo) DeepEmbeddeds(structName string) (ret StringSlice) {
strut := p.GetStruct(structName)
if strut.GetName() == structName {
e := strut.Embeddeds()
e.Filter(p.IsInterface).Each(ret.Append)
e.Filter(p.IsStruct).Each(func(s string) {
p.DeepEmbeddeds(s).Each(ret.Append)
})
}
return
}
Ain t exactly what i want,
still can t convert with ease,
but so much clearer.
If you put performance issue aside,
i feel like the only argument opposed so far
is a about
- a somehow more complex code,
- a subjective matter of taste.
for 1, take a look at SO and newbies questions
about chan, you should have some fun.
fun² I remember some trying to build very similar constructs on top of chan.
for 2,
2.1 YOLO, i want better structure to program faster, i might not be doing
the right thing because i ain t yet understood the language correctly, yet,
i want to benefit the whole environment provided by it, ultimately, that i
m right or wrong, does not matter in the immediate terms of getting
productive, i m only looking for ways to program faster by reducing all
those additional constructs.
In other words,
I want to trade *write speed* Vs *write clarity*.
See also that unwinding such constructs, when its not non sense, is trivial.
Thus, if you do a performance analysis and you find that construct in a hot
path, you can tell,
lets unwind it.
2.2 blah, if google wants to try to rule the world
with its internal guideline book,
well it look likes it might keep trying,
users will still look for this kind of structure, i believe.
Down that path, the question does not become,
what s acceptable for my guidelines book,
but,
how i can best handle user needs,
provides what s needed to avoid a disaster with the tools given by the
language.
Anyway, if golang is to be successful (I mean like java),
i don t doubt that down the road
it will come to something similar,
with generics, or not.
gettin' the pop corn : )
On Saturday, June 3, 2017 at 6:35:49 PM UTC+2, Egon wrote:
>
> On Saturday, 3 June 2017 13:11:04 UTC+3, mhh...@gmail.com wrote:
>>
>> Hi,
>>
>> yes generics / not generics.
>>
>> That is, in what i proposed, only the consumer is enhanced, thus generics
>> are not required anymore on the declarer, except for this conv method,
>> indeed.
>>
>> also as the declarer can rely on more powerful tool on the consumer,
>> it needs to declare less to able more.
>>
>> That being said,
>>
>> Can you take a look to that, genericity less, it works
>>
>> https://gist.github.com/mh-cbon/2062efef48e246592bdb0665f0ab8547
>>
>> IMHO, its simple, it does what i need, it helps me to avoid obvious
>> gotchas, after many attempt i feel satisfy,
>> please critic it.
>>
>
> I think this version is much clearer: https://play.golang.org/p/9DfxObeDj3
> :P
>
>
>> On Friday, June 2, 2017 at 2:59:41 PM UTC+2, gary.wi...@victoriaplumb.com
>> wrote:
>>>
>>> Generics enable more than just replacing loops. For example, they can
>>> enable libraries of generic algorithms to be used with any type of array.
>>> Here's an example:
>>>
>>> foo := GetArray()
>>> result := foo.Take(10).map(...).Sort(...).Reduce(...)
>>>
>>> That is simple to understand and in one line of code. Imagine the
>>> acrobatics (and lines of code) needed to do this using Go's loops!
>>>
>>> You can read my full article on why Go needs generics here:
>>> http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/
>>>
>>> On Friday, 2 June 2017 09:17:54 UTC+1, Florin Pățan wrote:
>>>>
>>>> Since everyone thinks it but nobody bothers to reply to it: this whole
>>>> thing you propose can be currently done with a for loop, which not only is
>>>> explicit about what it doing, but it also lets you control if you want to
>>>> exit early from it and so on. Complicating the whole language because
>>>> something is cool (yet looks like a really complex thing that you need to
>>>> think about while reading the code) is in no one's benefit. Stop trying to
>>>> avoid a couple of extra rows of for {} (where the third row is literally
>>>> just an "}") and start embracing the fact that you can understand the
>>>> code
>>>> by looking at it and not apply any complex mental acrobatics to figure out
>>>> what those three lines of code are doing. Your future self/person after
>>>> you
>>>> will thank you for that.
>>>
>>>
--
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.
