the way to explain it is this: *support for using
type-specific-but-parameterized written by A by caller B with their own
types not anticipated or known by A; the ability for B to easily say, "I
want A's excellent feature and I want to use it with my special B-only data
type."*
this cannot happen with a switch in A's code unless B rewrites it.
for a fixed set of types, this is possible and good. i rewrote the sort
package so that sort.Sort() has just this kind of type switch. if the slice
is byte, short, ... float,... string then it dispatches to a type-specific
version that is macro instantiated from one of three versions (integer,
float, string). this pays the interface tax once rather than n log n times.
it is 2x faster plus it is also parallel for another ~ 3/4 ncpus speedup.
that's my kind of code. even the most limited kind of generic can handle
this use.
but to make it work for a user's own types without code change? that needs
a greater magic.
On Tue, Sep 18, 2018 at 2:57 PM robert engels <reng...@ix.netcom.com> wrote:
> If you have type checking / casting / type select, whatever you want to
> call it in the “generic code”, it is not generic, and not re-usable.
>
> You can’t possibly know all the possible types, there may even be more
> additional primitive types, so the code is not resilient - Go 2.1 and all
> of your library code breaks?
>
> The caller will not have access to the source code (and certainly not want
> to read it to call a function). Nothing will be obvious as to what Sum can
> work on or what it does - in fact you can have very subtle errors because
> the code is duplicated across types.
>
> Besides those problems, even if it was somehow workable, the syntax reuses
> keywords in non-standard ways (for example even if this was adopted, why
> wouldn’t the syntax be:
>
> switch K {
> case (int64,unint64,…):
> blah blah blah
> case big.Int
> blah blah blah
> default:
> panic // implied
> }
>
> The compiler already knows K is a type…
>
> And yet more problems, because you probably need every combination of
> types if it has more than one, (depending on what the method does) — you
> need an n*n number' of case statements to implement it….
>
> I am just being realistic, and I don’t mean to be harsh, but I don’t think
> your proposal is going to be accepted, and I think it might be better if
> you spent more time listening to the criticism, and maybe reworking, than
> trying to defend it. I guess there is always the chance I don’t get it, but
> I think I do…
>
> Not sure how else to explain it.
>
>
> > On Sep 18, 2018, at 3:53 PM, Wojciech S. Czarnecki <o...@fairbe.org>
> wrote:
> >
> > On Tue, 18 Sep 2018 10:11:52 -0700 (PDT)
> > mhhc...@gmail.com wrote:
> >
> >> I agree with Robert, this is not re usable.
> >
> > What is not reusable? A generic Sum function allowed by
> > the CGG that can sum any type of any base that accidentally
> > has anything countable in it?
> >
> >> I much prefer this
> >>
> >> func Sum(some []K, add func(l,r K) K) (ret K) {
> >> for _, v := range some {
> >> ret = add(ret, v)
> >> }
> >> return ret
> >> }
> >>
> >> func main(){
> >
> >
> >> total := Sum([]int{1,2,3,4}, func(l,r int) int {return l+r})
> >> }
> >
> > How clever and generic it looks. Generic, javish and cpluplusish.
> > And how readable call site it gave.
> >
> > In CGG Go user code call is exactly the same for ANY type.
> >
> > total := Sum(x) // For var x []AnyType. ANY.
> >
> > var x []string
> > total := Sum(x)
> >
> > may return sum of all runes in all strings and sprintf-ed to
> > the resulting string.
> >
> >> this is not re usable.
> >
> > How can I call your example to get string result of sum of all
> > runes? CGG's is as with any other type: `total := Sum(x)`
> >
> > --
> > Wojciech S. Czarnecki
> > << ^oo^ >> OHIR-RIPE
> >
> > --
> > 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.
>
--
*Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>*
--
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.
