That is not true. Often, due to lack of generics things are passed as
interface{} or a sub interface, and then type checked/casted in the method.
When you refactor you will get no warnings that X no longer meets the contract.
You have no obvious way either by looking at the code to know which interfaces
a developer needs (or wants it) to implement. Things will fail at runtime,
People state this is a plus - yes it is - for small easily contained/understood
systems. As the application grows larger, this is a real bottleneck to
productivity.
Having ‘implements’ does nothing to harm the productivity - not having it hurts.
The opinion that well, since there is no implements I can define my own
interface, and pass some stdlib struct that I can’t control as an “implementor”
is hogwash. Because you also don’t control this code, the API is free to change
- breaking your code. This is why the “backwards implements” is a bad idea.
Having implements is the easiest to understand large systems - if you use
interface based design, you can get a full mental picture of the system, then
by looking at implementors you can determine the concrete options (performance,
capabilities, etc.)
Try working with any dynamic language that has duck typing - it is impossible
to refactor. Don’t take my word for it, just read any of the thousands of blog
posts covering it.
Go is no different.
Go was designed to replace scripting tools, and C tools (usually systems
level). It was not designed for large enterprise applications, and that is why
it falls down in many places. It doesn’t mean it isn’t GREAT for what it was
designed to do, and better than Java in many (most) of these cases. Large
enterprise apps, no way.
> On Sep 19, 2018, at 8:39 AM, Thomas Bushnell, BSG <tbushn...@google.com>
> wrote:
>
> 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
> <mailto: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
> <mailto:o...@fairbe.org>> wrote:
>
> >> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhhc...@gmail.com
> >> <mailto: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 <mailto: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
> <mailto:golang-nuts%2bunsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <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.
