Huh? Type safety is still checked by the compiler. Implements does nothing
except put a road-block in the way and prohibit you from making an
interface that some other package happens to implement.
On Wed, Sep 19, 2018 at 1:40 PM Robert Engels <reng...@ix.netcom.com> wrote:
> Go not having implements is a big problem when refactoring large Go
> systems especially because it doesn’t have generics - all type safety is
> gone and you fly by the seat of your pants.
>
> On Sep 19, 2018, at 4:26 AM, Wojciech S. Czarnecki <o...@fairbe.org>
> wrote:
>
> >> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhhc...@gmail.com wrote:
> >
> > The **stated** goal for adding some kind of generics to Go is
> > and always was "how to not repeat writing same code just for a type".
> >
> > Now above practical goal, in minds of many, somewhat morphed
> > to "Yeah, lets have real true generics so we can write/reuse
> > smart and clever code we once upon a time wrote for c++/java".
> > "So we need a way of expressing generic data in terms of other
> > generic data then use abstract alghoritm on that".
> > (Yep, team's proposal use: "in terms of operations")
> >
> > It now poisons all the proposals I've seen with syntax that
> > forces **user** of the code to **repeat** at the **call site**
> > type identifier for the sake of "code instantiation".
> >
> > Why? I think that's a mark of "one proper way for doing generics" burnt
> > on the popular mindset. As hard to overcome as notion that one needs
> > 'implements/implementing' to use interfaces.
> >
> > Does Go2 should have "implements" keyword added too?
> > `type mytype struct{...} : implements io.Writer, ..., ...`
> >
> > What?! "Compiler knows whether your type satisfies an interface"
> >
> > Yeah, and at the call site compiler **does know** the parameter
> > type too. This is the CGG basis.
> >
> >
> > 1. Find a way to write "some Go code" that is suitable for set of
> > types that have "something" in common.
> >
> > 2. Find a way to describe the set via the "something common"
> > that implementation for said set will use on objects of matching types.
> >
> > 3. It **MUST** read as Go: no instantiation at call site.
> >
> >
> > On Tue, 18 Sep 2018 15:22:01 -0700 (PDT)
> > mhhc...@gmail.com wrote:
> >
> >> I was referring to this code
> >>
> >> func (x type []K) Sum() (r type K) {
> >> }
> >>
> >
> >> I did not understand how "// For var x []AnyType. ANY. " relates to
> >> previous code.
> >
> > Previous code example was specific to `big.Int` type. Next I gave
> > a really generic usage example via the constraint that already is
> > described in CGG proposal: "type with given method implemented".
> >
> > With that constraint func Sum can be called on _any_ type that has
> > a method (*T) Add(T,T). And someone writing new code needs not to
> > change generic lib (as imputed), but she needs to provide for her
> > non-numeric or peculiar type a method (*T) Add(T,T). Then Sum works.
> >
> >> for your question about the rune, i guess it d be like this
> > [...]
> >> Consider Z,K as virtual types to be inferred from the call site.
> > Progress! As to inferred :)
> >
> > But I wanted return to be a string with sum of runes from all
> > input strings :) Leave it.
> >
> > In CGG such specialization takes place in a single to find and simple
> > to **read** 'case' code. The proposal's example Sum already has a single
> > piece of code that will be **reused** for all numerical types that user
> > **might** declare off builtin. With only two for type cases CGG's generic
> > Sum spans all types with numerical base and all types that provide their
> own
> > "me plus operator". With one case more it allows for set of types that
> have
> > "plus me operator". Code that can and will run for multitude of user
> types.
> >
> > Yet I still hear stubborn "not reusable!, not reusable! not generic!".
> >
> >> In regards to Russ Cox proposal this code is missing
> >> their explicitly declared contracts and the function instances
> declaration.
> >> On the other hand, this is so much more readable *to me*.
> >
> > The "real true generics" proposals are readable to people who took the
> > time and the training to accommodate to such List<Map<Hashable,Tuple>>
> > syntactical mess. But it is **against** Go philosophy of "readability
> first".
> > It excludes the legion who finds mental instantiations cumbersome at
> > reading time. It shifts their thought from "what this will do" to "in
> what
> > shape it will be".
> >
> >
> >> maybe it looks likes c++, i did not think it was a concern
> >> as long as it respected desired behaviors of good error reporting,
> >
> > It IS a MAIN concern. In fact it is a concern that the Go
> > team explicitly stated as a reason why Go1 is generics free.
> >
> >> good readability,
> > It has **no** readability for all but c++/java conditioned
> > and is an inexhaustible source of confusion in other languages
> >
> >> ease of usage.
> > leading to ubiquitous C&P in java/c++ application of generic libs.
> >
> >> speed of compilation,
> > [I assume it was not about c++ compiling]
> >
> > With CGG a single significant change to current gc parsing will
> > be in marking 'func' node so parser could swap the subtree when
> > it will see 'for type' while in declaration body.
> >
> > The only bigger chunk of new code in gc will be for contract
> > parsing and matching. Everything else needed for fast CGG
> > implementation already is working in the current gc.
> >
> > [ c++ and like approach ]
> >> proven useful
> > Proven as a source of confusion and bugs in analysis
> > linked above in thread (thanks for the link, Robert :).
> >
> >> and workable etc
> > Workable and ubiquitous. Like 'implements' before Go.
> >
> >> Anyways, I am polluting the thread against this proposal, sorry for
> that.
> >
> > It is not a pollution, really. I am glad I can discuss both "we need no
> > generics" and "we need practical approach" topics with avid users of
> > c++/java style generics. It may show me how to simplify and specify
> > my description of "craftsman's ways" to all c++<enslaved> :)
> >
> > P.S. (All) Take my apologies for "javish and cpluplusish" sarcasm.
> > I just am a bit resentful when I am pushed to fight strawmen about
> > CGG possibilities. Described, tabularized even, but not read. Not
> > to mention understood.
> >
> > I am patiently waiting for someone who at last will use the slider
> > and will read CGG proposal past the top example. Someone
> > leaving "it's not about generics I know" impulses aside.
> >
> > CGG is not about known, CGG proposal is about reusable code
> > written "in Go I know" hence easy to read and understand.
> >
> >
> > Peace,
> >
> > --
> > 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.
