Linked by Thom Holwerda on Mon 11th Feb 2013 22:59 UTC
General Development "I feel like writing about the Go programming language (or 'Golang') today, so instead today's topic is computer stuff. For the record, the language I've programmed the most in has been Python, so that’s the perspective I'm analyzing it from." Some good and bad things about Go.
Thread beginning with comment 552466
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[13]: My thoughts on Go
by satsujinka on Thu 14th Feb 2013 18:48 UTC in reply to "RE[12]: My thoughts on Go"
satsujinka
Member since:
2010-03-11

Why are you being obtuse?

I've already covered that it's not necessary to know whether a type implements some interface. The only time you need to know that is when you're passing an object to a function and that's a comparatively small amount of usage compared to what the function in question will actually do.

So, most of the code that you will read is going to be code that uses an interface to do something. Exactly like the function I gave. So it is always crystal clear what capabilities are at hand.

Reply Parent Score: 2

RE[14]: My thoughts on Go
by lucas_maximus on Thu 14th Feb 2013 19:43 in reply to "RE[13]: My thoughts on Go"
lucas_maximus Member since:
2009-08-18

I explained it up-teenh times as my Grandfather would say.

It is about readability and I want to know before compile whether I am writing the code correctly ... just an odd habit I have.

I think unless the code is crytal clear on its intent then it is not correct.

I work with a lot of developers, some are my skillset, some are better.


Some have re-skilled via courses and we obviously have juniors.

It is easier to tell them with a language when this word is put in front of a variable that is changes the accessibility of that variable ... same with the interfaces.

For example.

I can tell them "If the interface has these methods defined then anything implementing them must implement them".

It is crystal clear, there is no implied. The compiler will kick your ass straight away even if the IDE of choice doesn't tell you before hand.

I believe you are simply missing the point on purpose at this point in the discussion.

Reply Parent Score: 2

RE[15]: My thoughts on Go
by satsujinka on Thu 14th Feb 2013 20:08 in reply to "RE[14]: My thoughts on Go"
satsujinka Member since:
2010-03-11

As I've said "up-teenth times" it is still crystal clear.

Your example makes sense in Go. The issue that you're missing is that the only time it matters if something does implement an interface is when you're using an interface as a parameter. In which case your example is more literally:

"Any valid object for this parameter must have the methods defined by this interface"

And again, if it doesn't the compiler will "kick your ass straight away".

In my opinion, you're focusing way too much on the definition of an object and no where near enough on actually using the object. So I'll repeat:

An object has methods defined with it, these methods are sufficient to tell you what the object can do. Interfaces are a separate concept designed to provide a contract for parameters. Thus mixing the interface with the object is redundant.

Go as a language tries to avoid redundancy. Maybe this hurts readability in your eyes, but in practice there's no difference and the "issue" you seem to have never comes up.

Reply Parent Score: 2