I agree. I think Microsoft's implementation of extension methods
works well in C#:
http://msdn.microsoft.com/en-us/library/bb383977.aspx
And I think it would be consistent with Go's design paradigm to add
this feature. Without it, you are basically just subclassing when you
do something like this:
type MyString string;
func (s MyString)Print() {}
Not much different than:
class MyString : String
{
void Print() {}
}
On Nov 14, 9:08 pm, Quenio <
queniodossan...@gmail.com> wrote:
> Hi All,
>
> After my original query, I've started coding with Go a little more,
> and I am really finding that, because of the package scope limitation,
> the decoupling of types andmethodsis not useful at all!
>
> I may be missing something here, but doing something like this:
>
> typeMyType struct {
> myField OtherType;
>
> }
>
> func (self MyType) MyMethod() MyResulType {
> return something;
>
> }
>
> Is not different at all from something like:
>
> class MyType {
> myField OtherType;
> func MyMethod() MyResulType {
> return something;
> }
>
> }
>
> Especially because both thetypeand the method have to be in the same
> package anyways. In fact, the decoupling only makes you have totype
> much more repetitive code when you have severalmethods:
>
> func (self MyType) MyMethod1() MyResulType {
> return something;
>
> }
>
> func (self MyType) MyMethod2() MyResulType {
> return something;
>
> }
>
> func (self MyType) MyMethod3() MyResulType {
> return something;
>
> }
>
> func (self MyType) MyMethod4() MyResulType {
> return something;
>
> }
>
> "(self MyType)" is totally repetitive!
>
> Of course, you can say that you can applymethodsto things other then
> structs, but this could be valid:
>
> typeMyString string {
> > >>> Should I use my own stringtypein all my API's?
>
> > >> No.
>
> > >>> It would be unfamiliar tonewAPI users to see atypethat just so
> > >>> happens to be a string.
>
> > >>> I shouldn't have to use a customtypein my API just so that I have
> > >>> some convenience in my API's implementation.
>
> > >>> A customtypeshould only be used if it will make the API more useful,
> > >>> clear to its users.
>
> > >>> Also, if every API provider decides to have its own custom version of
> > >>> string, how much more confusing will it be for users of those APIs.
>
> > >> These are all good reasons for the answer to be no.
>
> > >> Getting back to your original question, about being able todefine
> > >>methodsfor other package's types, the fundamental problem is that
> > >> this leads to confusion during dynamic interface checks.
> > >> For example, suppose you like seeing ints print in hexadecimal,
> > >> so youdefinea method func (i int) String() string that returns
> > >> a hexadecimal string. I prefer octal, so Idefinemy own