```
type WithSharedOption interface {
SomeMethod()
}
type OptionA struct {
}
func (a OptionA) SomeMethod(){}
type OptionB struct {
}
func (b OptionB) SomeMethod(){}
//without generics
func WithShared(option WithSharedOption){}
func WithANotShared(option OptionA){}
//with generics
func With
This is first quality human material! Thanks for reviving it!!!
El miércoles, 27 de julio de 2022 a las 6:07:17 UTC-3,
axel.wa...@googlemail.com escribió:
> This thread has been resurrected after 9 years of inactivity. From what I
> can tell, there is no reason to do so now.
> In particular, th
As a note, this is how I solve this problem without generics:
https://go.dev/play/p/nsDca0McADY
On Wednesday, July 27, 2022 at 2:54:20 PM UTC-7 John wrote:
> With 1.18 generics, I'm curious if anyone has a good solution using
> generics to solve the optional argument that can be used in multipl
With 1.18 generics, I'm curious if anyone has a good solution using
generics to solve the optional argument that can be used in multiple method
problem.
So say I have two methods, .A() and .B(). Both accept optional arguments
where some optional arguments might be shared.
Here is a very loose
Cool stuff!
On Wed, Jul 27, 2022 at 3:46 PM Brian Candler wrote:
> I see. There's a concrete benefit in using the waitgroup though: it would
> have shown you the second write blocking.
> https://go.dev/play/p/WNHRkkUUZUt
>
> On Wednesday, 27 July 2022 at 10:43:01 UTC+1 aravind...@gmail.com wrote
I see. There's a concrete benefit in using the waitgroup though: it would
have shown you the second write blocking.
https://go.dev/play/p/WNHRkkUUZUt
On Wednesday, 27 July 2022 at 10:43:01 UTC+1 aravind...@gmail.com wrote:
> Thanks Brian, Got it.
> "A send cannot take place until the reader is r
Thanks Brian, Got it.
"A send cannot take place until the reader is ready to receive." . So an
unbuffered channel does not have the same behaviour as a buffered channel
of size 1, fair.
I understand part about the waitGroup, I copy pasted code used to tutor the
newcomers to programming itself.
On
This thread has been resurrected after 9 years of inactivity. From what I
can tell, there is no reason to do so now.
In particular, the quoted 4 years have passed three times over since the
original open sourcing of Go, so they are clearly irrelevant.
Let dead threads rest in peace.
On Wed, Jul 27
If Google stop developing Go, I think we just need to fork main repo and
start United Gophers Foundation. :D
wtorek, 26 lipca 2022 o 17:01:17 UTC+2 richar...@gmail.com napisał(a):
> Yeah, and GMail and Google Search: their days are numbered
>
> On Sunday, July 28, 2013 at 10:25:11 AM UTC-7 Starf
BTW, using time.Sleep() to keep goroutines running is poor practice.
What I suggest is using a sync.WaitGroup. Call wg.Add(1) for each
goroutine you start; call wg.Done() when each goroutine ends; and call
wg.Wait() to wait for them.
https://go.dev/play/p/INl7BxG0ZSU
On Wednesday, 27 July 2022
Unless a channel is buffered, it is synchronous. A send cannot take place
until the reader is ready to receive.
You can make it buffered using
numCh = make(chan int, 1)
go write()
go read()
Or you can have two calls to read():
numCh = make(chan int)
go write()
go read()
Hi All,
When I was explaining basics of channels to newcomers, I was using the
below example
https://go.dev/play/p/xx2qqU2qqyp
I was expecting both Write 5 and Write 3 to be printed. But only Write 5
was printed. I couldn't reason out the behaviour, can somebody point out
what I am assuming wrong
12 matches
Mail list logo
