We've seen a fair amount written about concurrency in Go, but I really wanted to spend some time digging into Go's object model. This article is a result, and covers embedding, interfaces and packages as compared to classical languages like Ruby. I hope that some people find the examples helpful.
Ruby is a classical langauge?
Does that mean I am a dinosaur?
If you notice any errors, please let me know (here). Thanks!
It is possible to overrideSpares()
on Bicycle and still reference the embeddedParts.Spares()
. This feels almost like inheritance, but embedding does not provide polymorphism. The receiver ofSpares()
will always be of type Parts, even when called directly from a Bicycle.
--
I meant to say the receiver of Parts.Spares() will be of type parts when delagated to through Bicyle. It will probably be clearer if I swap some sentences around. Override may not be the best word, because of other connotations in programming languages.
Thanks for the feedback. FYI, this is what Effective Go has to say on the subject:
"There's an important way in which embedding differs from subclassing. When we embed a type, the methods of that type become methods of the outer type, but when they are invoked the receiver of the method is the inner type, not the outer one. In our example, when the Read
method of abufio.ReadWriter
is invoked, it has exactly the same effect as the forwarding method written out above; the receiver is the reader
field of theReadWriter
, not the ReadWriter
itself."
--
Here's a debate on GoThe question is how can you have concurrency without effective error handling?Is this where Bertrand Meyer's Design by Contract would be most useful?
On Monday, January 14, 2013 11:36:25 PM UTC-5, Nathan Youngman wrote:
--
Meh, after reading I place that article in the 'no press is bad press' category.
--
I'm honestly surprised pythonistas aren't more upset about gofmt.
// I know the code will ALWAYS get here// because no one can throw an exception in the middlef.Close()
Indeed, I think my point has been made for me.
I'm honestly surprised pythonistas aren't more upset about gofmt.
On 16/01/2013, at 8:10, Patrick Mylund Nielsen
<pat...@patrickmylund.com <mailto:pat...@patrickmylund.com>> wrote:
To be fair, asynchronous exceptions do exist in other languages.
They're just incredibly dangerous since they can interrupt anything
at any point in a thread. Go is much safer and saner in that respect.
On Tue, Jan 15, 2013 at 3:06 PM, Dave Cheney <da...@cheney.net
<mailto:da...@cheney.net>> wrote:
Exactly. My favourite point about this class of article is how
they throw stones without providing a modern replacement -- I
could equally parry with "exceptions?!? How quaintly 1980's of you".
The comment about panic being a sneaky exception class private to
the runtime shows a clear lack of understanding of the difference
between the exceptional, a programming error leading to an
uncorrectable bounds check failure at runtime, and the mundane
class of errors like io.EOF.
The continued calls for exception style error handling show a
failure to think concurrently. How exactly would you pass an
exception between goroutines ? I would imagine it would be some
sort of interface value that can be passed via a channel. Oh,
wait, we already have that today, it's called error.
Dave
On 16/01/2013, at 7:55, minux <minu...@gmail.com
<mailto:minu...@gmail.com>> wrote:
On Wed, Jan 16, 2013 at 4:53 AM, Dave Cheney <da...@cheney.net
<mailto:da...@cheney.net>> wrote:
Meh, after reading I place that article in the 'no press is
bad press' category.
I'd say the author just pointed out all the points I love about
Go even though
he/she strongly thought that one of them was '70 style and
out-dated (and i disagree).
--
--
Job,Interesting example. I'll have to read through it tonight.Cheers,jsw
--