That's a different case than one which "implements" addresses. You don't
need "implements" to address that problem, if you think it's a problem.
Adding "implements" doesn't help. I understand there are people who think
adding generics might help, but that's a different thing.
On Wed, Sep 19, 2018 at 4:04 PM robert engels <reng...@ix.netcom.com> wrote:
> 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>
> 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.
