Re: [go-nuts] Thinking OO virtual function in Go

On Thu, Nov 24, 2016 at 10:00 AM, Haddock wrote: > > This is merely resorting to a shared function. This does not really > cover overwriting in the OO sense. The article I mentioned shows how > to do this: > http://objectscape.blogspot.de/2013/09/inner-pattern-to-mimic-method.html Not really! Ton

Re: [go-nuts] Re: Thinking OO virtual function in Go

Hi, On Thu, Nov 24, 2016 at 9:33 AM, Haddock wrote: > > Here is another blog that shows a way how to do this: > http://objectscape.blogspot.de/2013/09/inner-pattern-to-mimic-method.html > Clever! I would like, though, to underscore the conclusion reached by the original post author: My preli

Re: [go-nuts] Thinking OO virtual function in Go

​ As I said ​ ​ before, Go's flavor of OO is different from that of other languages. Don't try to map concepts one-to-one, or you will end up with very contrived solutions. Always look at the big picture (why am I doing this?) and don't get side-tracked by synthetic examples. Most important is def

Re: [go-nuts] Thinking OO virtual function in Go

On Wednesday, November 23, 2016 at 5:17:11 PM UTC+2, Tong Sun wrote: > > Can you make it work on play.golang.org, from this code > https://play.golang.org/p/QjCtD9rGpa, according to your plan? > For this specific example, something like this: https://play.golang.org/p/FsorWRaLKk /npat -- You

Re: [go-nuts] Thinking OO virtual function in Go

Wed, Nov 23, 2016 at 4:05 AM, Nick Patavalis > wrote: > >> Hi, >> >> In your *second* example, making Output() a method of Animal will work, >> since it uses only the members (fields) of Animal, and not the fields of >> specific animals (or any behavior that v

Re: [go-nuts] Thinking OO virtual function in Go

hetic ones. /npat On Wednesday, November 23, 2016 at 6:08:00 AM UTC+2, Tong Sun wrote: > > No Nick, making Output() a member method won't work. > See my OP and Jesse's answer. I.e., I have to change it from a member > function to a pure function. > > On Tue, Nov 22, 20

Re: [go-nuts] Thinking OO virtual function in Go

Hi, There is no direct mapping of what you can do with virtual functions in other OO languages, and Go. There are different compromises you have to make; because of this, synthetic examples will probably not help much. That being said, in the case of your last example I would make Output() a

Re: [go-nuts] Re: Stopping a server

On Oct 28, 2016 14:48, "Peter Mogensen" wrote: > > So ... bottom line ... defining Server objects as one-shot/single-use allows you to define the Kill()/Shutdown() semantics to simply exhaust that single-use. (an being idempotent) ... making it irrelevant whether the server has actually been start

Re: [go-nuts] Re: Stopping a server

On Oct 28, 2016 14:32, "roger peppe" wrote: > > Yes, that's right. The main difference from a context is that a context provides > no way to know when things shut down. This, I think, is by design - things > like ErrGroup provide that functionality when needed. Yes, exactly. /npat (sent from my

Re: [go-nuts] Re: Stopping a server

By considering the server creation and starting out-of scope, rog's approach in-effect assumes that a worker instance is the same as a worker "run". Once a worker "w" is created it is considered "running" and once it's stopped, there is no way to re-start it. You must create a new instance. This si

Re: [go-nuts] Re: Stopping a server

On Fri, Oct 28, 2016 at 8:15 AM, Peter Mogensen wrote: > > The point being that it's up to the user of the interface how to specific > Server implementation should work. > Yes, of course, but an interface with just two methods (Serve / Stop) is not enough to provide race-free semantics (unless yo

Re: [go-nuts] Re: Stopping a server

On Thu, Oct 27, 2016 at 11:11 PM, Peter Mogensen wrote: > > The problem you seem to be trying to solve here is for the caller of > Shutdown() to know when the Server has exited Serve(). > The way to do that under "my" semantics to implement a Server letting you > wait for it to be ready to acknowl

Re: [go-nuts] Re: Stopping a server

Hi, On Thu, Oct 27, 2016 at 9:34 PM, Peter Mogensen wrote: > > Technically that depends on the Server implementation. > But in the provided http.Server extension, the answer is "nothing": > > func (srv *Server) Shutdown() { > srv.runlock.Lock() > defer srv.runlock.Unlock() >

[go-nuts] Re: Stopping a server

On Thursday, October 27, 2016 at 6:35:40 PM UTC+3, Peter Mogensen wrote: > > It's a valid question whether Context is the concept to use for starting > and stopping server instances. ... I'm not fully convinced. It seems to > me it's more meaningfull for more transient things like Requests. On Thu

[go-nuts] Stopping a server

Hi, I'm writing a package that allows the user to create and start server instances. A server instance is created like this: srv := pkg.NewServer( ... params ... ) and started like this: err := srv.Start() Start does not normally return (unless an unrecoverable error occurs). The user code

Re: [go-nuts] Re: do i need to wait all child routine exit

On Tuesday, October 25, 2016 at 5:17:10 PM UTC+3, Axel Wagner wrote: > > I suggest using errgroup > (and/or context.Context in > general) instead of rolling your own cancellation and timeout logic. It > shoul

[go-nuts] Re: do i need to wait all child routine exit

Hi, You don't *need* to wait for the goroutines to exit, per se, but, as far as I can tell, your code will panic when it "return"s and one of the still-running resolver goroutines try to send to the closed channel. One solution would be *not to close the channel upon return*. The channel will

[go-nuts] Re: Append consecutive slices, same underlying array

Opened issue here: https://github.com/golang/go/issues/17530 /npat On Thursday, October 20, 2016 at 5:22:27 PM UTC+3, T L wrote: > > yes, you are right. You can file an issue at > https://github.com/golang/go/issues > > On Thursday, October 20, 2016 at 9:11:14 PM UTC+8, Nick

[go-nuts] Append consecutive slices, same underlying array

Hi, It seems that the built-in append does not check for a situation like the following, and needlessly copies data, when it could avoid it. func appendBytes(a, b []byte) []byte { if len(b) == 0 { return a } // Shouldn't append() check for somethi

[go-nuts] [ANN] crc16

Hi, Cleaned this up and put it in a repo... just in case someone else might find it useful, as well: https://github.com/npat-efault/crc16 Package crc16 is a Golang implementation of the 16-bit Cyclic Redundancy Check, or CRC-16 checksum. The package's API is almost identical to the standard-