would not it be nice to write []string{"hello}.Map(strings.ToUpper) ? 

And so for userland types the language accept, 
[]*MyType.Filter(func(*MyType)*MyType).Map(...).First()//etc.

IRL, because the total lack of such struct in the language might let you 
think the idea is superfluous with the currrent 
language/idioms/whateveryounameit, 
I have this example i like,

// GetByID read the Tomate of given IDfunc (t Controller) GetByID(getID string) 
(jsonResBody *Tomate, err error) {
        t.backend.Transact(func(backend *Tomates) {
                jsonResBody = backend.
                        Filter(FilterTomates.ByID(getID)).
                        First()
        })
        if jsonResBody == nil {
                err = &NotFoundError{errors.New("Tomate not found")}
        }
        return jsonResBody, err
}


The code is not cluttered with extra if/else/for statements that i d have 
to introduce using regular constructs proposed by the language.


What are the example that needs extended generic support that interface can 
fulfilled ?
This one ?

type B string

func A([]string){}

func main(){ 
 var x []B
 A(x)
} 

? 
What else chan  ?
https://gist.github.com/mchirico/df9fad3e7a5ea0c4527a ?
map ?




in all cases, it ends up with a manual conversion should occur, can t the 
language handle it ?
Do the compatibility check needed to slice conversion and produce the 
results or err appropriately.
Even better, take advantage of it to implement compilation rules ?

sX, err := conv([]string, x) or panic(err)
A(sX)

outChan, err := conv(<- chan /whatever compatible/, inputChan) or panic(err)

Are there more examples in sight ?




On Wednesday, May 24, 2017 at 9:52:27 AM UTC+2, mhh...@gmail.com wrote:
>
> see the title, only for what s needed 
> Slice/Splice/Each/Map/First/Last/Reverse/Sort ect ect not len, for reason. 
> so interface system serves the userland by its definition of struct, and 
> the basic slice type provided by the language is fully operational, without 
> breaking, btw. i don t go further in evaluation, i leave that to the 
> reader, just trying to work decently.
>

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