I moved reply to the separate thread.
Subject: "Is "Craftsman's approach" proposal generic enough?"
https://groups.google.com/d/msg/golang-nuts/FOGMEFlL04s/kGQ9mKSsCgAJ
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
You received this message because you are subscribed to the Google Groups
Not a problem!
On Thursday, September 20, 2018 at 11:55:04 AM UTC-4, Michael Jones wrote:
>
> [Apologies to Dave Cheney, timely pushback for David Collier-Brown]
>
> David, I disagree and suggest your remark is not well considered. Three
> replies, one per sentence.
>
Not a problem! Indeed,
[Apologies to Dave Cheney, timely pushback for David Collier-Brown]
David, I disagree and suggest your remark is not well considered. Three
replies, one per sentence.
*"Right now, this looks like the third draft of an academic project."*
Not to me. This reads like years of thought and discussion
Right now, this looks like the third draft of an academic project. It
suffers badly by comparison to make(), the existing mechanism.
Can we see some more alternatives, please?
--dave
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
Thank you to everyone who has contributed to this thread.
It is time for everyone to take a break for 48 hours. After this time if you
feel strongly that there is a point which you must continue to debate please do
so, but be mindful that many words have already been spent in this thread and
On Wed, 19 Sep 2018 09:32:39 -0500
Robert Engels wrote:
> This is not what I am referring to. I am stating that with N generics types
> in a method the developer needs to write NxN case methods. Not feasible.
Wrong. On two axis.
1. As stated in proposal, CGG has no "generic type" (generic
There is a reason that Google has moved to Angular2 from AngularJS. As
applications get larger you need more structure in order to maintain them.
Implements is one of the ways to provide the needed structure. I know having
structure goes against hacking. Try having a conversation in a room with
On Wed, Sep 19, 2018 at 4:04 PM robert engels wrote:
>
> 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 -
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,
+1 Go doesn't need generics, in fact it goes against its philosophy and
core values.
Lack of generics was one of the reasons I moved to Go, I worked with Java
since version 3, and I do believe that generics just made Java worse.
Regards.
понедельник, 17 сентября 2018 г., 19:04:26 UTC+3
This is not what I am referring to. I am stating that with N generics types in
a method the developer needs to write NxN case methods. Not feasible.
Sent from my iPhone
> On Sep 19, 2018, at 9:25 AM, Wojciech S. Czarnecki wrote:
>
> On Wed, 19 Sep 2018 06:52:09 -0500
> Robert Engels wrote:
On Wed, 19 Sep 2018 06:52:09 -0500
Robert Engels wrote:
> Also, I did read what you wrote. I questioned “what happens when you have N
> different generic types in the call signature. The select type statement
> has N*N cases. “. You did not respond.
The object code (i.e. ssa then machine) is
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
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 wrote:
> Go not having implements is a big problem
Anyone who doesn't want some form of generics is in favor of a bad status
quo. Now I'll be fine without user defined generics if Go provided a dozens
of built-in compile time safe generic data structures like trees, sets,
tuples, ordered maps, weakmaps perhaps WITH a complete set of methods
Also, I did read what you wrote. I questioned “what happens when you have N
different generic types in the call signature. The select type statement has
N*N cases. “. You did not respond.
On Sep 19, 2018, at 4:26 AM, Wojciech S. Czarnecki wrote:
>> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT)
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 wrote:
>> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT)
> 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
I was referring to this code
func (x type []K) Sum() (r type K) {
for type switch {
case K range int64(), uint64(), float64(), complex128():
for _, v := range x {
r += v
}
case K big.Int:
for _, v := range x {
r.Add(r,v)
}
break
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
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
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
Thomas, Good morning old friend.
Yes the implementation of axiomized arithmetic has proven difficult. Not
that it is too hard, but because (I think) it requires a mindset alien to
most developers. It works very well in the symbolic algebra system Axiom
which is the acme; A matrix is not just "a
Eric,
This is the sort of situation where a tool could help.
If the tool detects that you've written a generic type/function but only
then instantiated it once, that could lead you to rewrite the type/function
non-generically for the type(s) actually used in the instantiation.
Alan
On
On Tue, Sep 18, 2018 at 6:21 AM Robert Engels wrote:
> I am going to refer everyone involved in this discussion on generics to
> this once again. I know it is long, read the summary... but it’s important:
>
>
> https://www.researchgate.net/publication/236644412_Adoption_and_Use_of_Java_Generics
I agree with Robert, this is not re usable.
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})
}
On Tuesday, September 18, 2018 at
On Tue, 18 Sep 2018 11:10:00 -0500
robert engels wrote:
> I’ve said many time, the CGG example you cite here is not generic code.
I do not want neither write nor **READ** Go++ code.
CGG is called Craftsman's for a reason.
Its for writing and **reading** real production code. It disallows, by
I’ve said many time, the CGG example you cite here is not generic code. If I
want to pass a different user type and use that method I can’t, I need to
change the source of Sum(). That is not generic programming...
> On Sep 18, 2018, at 10:58 AM, Wojciech S. Czarnecki wrote:
>
> On Tue, 18 Sep
> On Sep 18, 2018, at 9:51 AM, Wojciech S. Czarnecki wrote:
>
> On Tue, 18 Sep 2018 08:19:13 -0500
> Robert Engels wrote:
>
>> So even when using generics you still need to be able to write
>> understandable code.
>
> **need to be able to write understandable code**
> Yes. This thread is
One thing I've always liked about Go is the ability to define your own
types based on the built-in ones. Although the built-ins don't have methods
themselves, you can still add them to your own types and satisfy interfaces
in that way.
This enables us to define simple collection types such as
On Tue, 18 Sep 2018 08:19:13 -0500
Robert Engels wrote:
> So even when using generics you still need to be able to write
> understandable code.
**need to be able to write understandable code**
Yes. This thread is about whether within Go generics proposal this is possible
and if not possible -
I am going to refer everyone involved in this discussion on generics to this
once again. I know it is long, read the summary... but it’s important:
https://www.researchgate.net/publication/236644412_Adoption_and_Use_of_Java_Generics
> On Sep 18, 2018, at 7:52 AM, Wojciech S. Czarnecki wrote:
>
Here is a very common problem with generics...
Everyone understands the concept of a tuple/pair. Pretty easy, you have
getElement0 and getElement1 methods.
Now a piece of code needs a KeyValue pair used in a map. So, with generics
someone says, oh, I already have this pair class, I’ll just
On Tue, 18 Sep 2018 04:38:55 -0700 (PDT)
ffm2...@web.de wrote:
> Every average Joe Java boilerplate coder gets along with generics.
Barely, if at all, understanding whats under.
"Smart Copy Paste ... A book for normal programmers"
On Tue, Sep 18, 2018 at 1:04 PM wrote:
> It would be nice, for example, to have a full range of collection types in
> the standard library without the need to use interface{}, type assertions
> and the performance overhead of 'boxing'.
>
>From the earliest days of Object Oriented Programming,
在 2018年9月18日星期二 UTC+8下午7:29:37，Chris Hopkins写道：
>
> Pondering this, my concern is that it might become too powerful. I'm
> scared this will make it harder to work out what someone has done if
> there's too much indirection and magic added on top. It feels like it could
> be a really *really*
Am Dienstag, 18. September 2018 13:29:37 UTC+2 schrieb Chris Hopkins:
>
> Pondering this, my concern is that it might become too powerful. I'm
> scared this will make it harder to work out what someone has done if
> there's too much indirection and magic added on top. It feels like it could
>
Pondering this, my concern is that it might become too powerful. I'm scared
this will make it harder to work out what someone has done if there's too
much indirection and magic added on top. It feels like it could be a really
*really* big hammer.
I don't buy the argument " those who prefer to
+1
IMO the place generics would be useful is reducing the use of the empty
interface and then a type switch. Otherwise I don't see quite what people
are doing that wouldn't be better done with interfaces.
In the past I mistakenly tried to declare local methods on the builtin
types. Revisiting
Although I respect the opinions expressed here, I think you might be
pleasantly surprised by how the proposed design would dovetail with the
rest of Go and make a number of things much more convenient than they are
at present.
It would be nice, for example, to have a full range of collection
When I was a new Go user and didn't fully understand how to use the
language, I really wanted Generics.
But the more Go experience I gained, the more I realized that Generics
wouldn't have helped nearly as much as I had assumed; in fact, they would
have added significant complexity and
On Mon, 17 Sep 2018 11:18:51 -0700 (PDT)
> Eric Johnson
>> jucie.andr...@zanthus.com.br
I hope that the team will make an informed decission and assesment taking
into account both the opinion of the community and its good ideas to make
something simpler. See all community proposals at
On Monday, September 17, 2018 at 9:04:26 AM UTC-7, jucie@zanthus.com.br
wrote:
>
> Go core team is working hard to bring generics to the language because
> several people asked for it. With all due respect for those users and for
> people working hard to make generics a reality, I feel
43 matches
Mail list logo
