[go-nuts] The problem of abuse use of interface{}

So, does anybody think that most of the go library, including the
built-in packages, are kinda use interface{} too often?

I take parser.ParseFile (in go/parser package) as an example, which was
recently used by myself. The function signature is:

func ParseFile(fset *token.FileSet, filename string, src interface{},
mode Mode) (f *ast.File, err error)


The src argument is defined with type interface{}. From the document,
its type could be string, []byte, or io.Reader.

Here, the largest problem is that the compile cannot help anything with
assuring src is of one of the above three types. In case, io.Reader
changes, or some change in the caller side that makes the implementation
doesn't satifiy io.Reader, the compler will never complain. We have to
find the problem on runtime(testcases or online service).

I think we can make it much better.

One proposal is to introduce the union of types. The grammar is like this

func ParseFile(fset *token.FileSet, filename string, src
string|[]byte|io.Reader, mode Mode) (f *ast.File, err error)


The compiler will check the following things:

- In the caller side, the value given to src shoud be assignable to
either of the type.
- Inside the function, src can be only asserted as one of the types
or a type one of the delcared type can be converted to.

I'm open with details like

- The final grammar other than type | type | ...
- one can define a named type like this: type SourceType
string|[]byte|io.Reader

This can also be considered as a better alternative to function
overloading, which is not introduced in Go.

Any discussion is welcome!

Thanks!


--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/d/optout.

On Wednesday, 10 September 2014 18:51:34 UTC+3, David DENG wrote:

So, does anybody think that most of the go library, including the
built-in packages, are kinda use interface{} too often?

I take parser.ParseFile (in go/parser package) as an example, which was
recently used by myself. The function signature is:

func ParseFile(fset *token.FileSet, filename string, src interface{},
mode Mode) (f *ast.File, err error)


The src argument is defined with type interface{}. From the document,
its type could be string, []byte, or io.Reader.

Here, the largest problem is that the compile cannot help anything with
assuring src is of one of the above three types. In case, io.Reader
changes, or some change in the caller side that makes the implementation
doesn't satifiy io.Reader, the compler will never complain. We have to
find the problem on runtime(testcases or online service).

I think we can make it much better.
One proposal is to introduce the union of types. The grammar is like this

func ParseFile(fset *token.FileSet, filename string, src
string|[]byte|io.Reader, mode Mode) (f *ast.File, err error)

The compiler will check the following things:

- In the caller side, the value given to src shoud be assignable to
either of the type.
- Inside the function, src can be only asserted as one of the types
or a type one of the delcared type can be converted to.

I'm open with details like

- The final grammar other than type | type | ...
- one can define a named type like this: type SourceType
string|[]byte|io.Reader

This can also be considered as a better alternative to function
overloading, which is not introduced in Go.

Any discussion is welcome!

Thanks!

On Wednesday, September 10, 2014 9:21:34 PM UTC+5:30, David DENG wrote:

So, does anybody think that most of the go library, including the built-in
packages, are kinda use interface{} too often?

I take parser.ParseFile (in go/parser package) as an example, which was
recently used by myself. The function signature is:

func ParseFile(fset *token.FileSet, filename string, src interface{}, mode
Mode) (f *ast.File, err error)


The src argument is defined with type interface{}. From the document, its
type could be string, []byte, or io.Reader.

Here, the largest problem is that the compile cannot help anything with
assuring src is of one of the above three types. In case, io.Reader changes,
or some change in the caller side that makes the implementation doesn't
satifiy io.Reader, the compler will never complain. We have to find the
problem on runtime(testcases or online service).

I think we can make it much better.

One proposal is to introduce the union of types. The grammar is like this

func ParseFile(fset *token.FileSet, filename string, src
string|[]byte|io.Reader, mode Mode) (f *ast.File, err error)


The compiler will check the following things:

In the caller side, the value given to src shoud be assignable to either
of the type.
Inside the function, src can be only asserted as one of the types or a
type one of the delcared type can be converted to.

I'm open with details like

The final grammar other than type | type | ...
one can define a named type like this: type SourceType
string|[]byte|io.Reader

This can also be considered as a better alternative to function
overloading, which is not introduced in Go.

Any discussion is welcome!

Thanks!

On 13 September 2014 18:54, Benjamin Measures wrote:

I think this was just a matter of inexperience.

Given the context, your suggestion of inexperience is easily
misunderstood.

On Tuesday, 16 September 2014 00:25:54 UTC+1, Andrew Gerrand wrote:

By whom? Robert readily admits that in retrospect he would have done
things differently.

On Friday, 12 September 2014 10:25:00 UTC+1, Hariharan Srinath wrote:

Method overloading would be the standard solution in other languages for
situations like this. However the FAQ says "Experience with other languages
told us that having a variety of methods with the same name but different
signatures was occasionally useful but that it could also be confusing and
fragile in practice"

I'm curious to understand more about trade-offs that prompted this choice
since in cases like this kind of use of interface{}, the choice pushes what
could have been a compile time check to a runtime check with equal or more
confusion/fragility implications.

On Friday, 12 September 2014 10:49:35 UTC+1, rog wrote:

I think this was just a matter of inexperience. This API was implemented
quite early on, and I seem to remember the author (Robert Griesemer?)
saying that he would have done it differently if he was doing it again.

Given the context, your suggestion of inexperience is easily
misunderstood.