FAQ
My terminology might be off, but what i would like to see, would be
interface usage declarations in struct definitions eq:

type File struct : io.Reader, io.Writer {
*file
}

This would make it clearer, what interfaces the struct has or is meant to
implement and also aid in code generation.
Currently i have to manually check all the methods on a struct to see, if
it supports a given interface or not.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Andrey mirtchovski at May 14, 2013 at 6:01 am
    This has been discussed at least forever on the mailing list. The
    consensus is that rather than forcing everyone to explicitly state
    what they support, you can instead use the type system to verify it
    for them at runtime and at no extra clacking cost:

    http://play.golang.org/p/VmI9264X9q

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andrey mirtchovski at May 14, 2013 at 6:02 am
    s/runtime/buildtime/ :)

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John Doe at May 14, 2013 at 6:06 am
    I meant that this would help during the coding phase, not the runtime.
    It's getting relatively timely to check, if the struct has the exact method
    with the exact signature, if they could all be declared in one place.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jesse McNelis at May 14, 2013 at 6:25 am

    On Tue, May 14, 2013 at 4:06 PM, John Doe wrote:

    I meant that this would help during the coding phase, not the runtime.
    It's getting relatively timely to check, if the struct has the exact
    method with the exact signature, if they could all be declared in one place.
    They can't. There are an infinite number of interfaces that a type can
    satisfy, most of which are yet to be created.

    --
    =====================
    http://jessta.id.au

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitri Shuralyov at May 14, 2013 at 9:03 pm
    You're right, it would be convenient to see that information while writing
    code.

    However, forcing this to be explicit has many disadvantages that others
    have pointed out, so that's not the way to go.

    Instead, since this information can be derived from existing Go code, this
    is something your tools (that are more advanced than a basic text editor)
    can help you with visualizing. Think of it as a dynamic view into your code
    that exposes more info than is written in the source files. Best of both
    worlds (easy to change, easy to find the info you seek). This is something
    I can add to my Conception<https://github.com/shurcooL/Conception#conception>project, but I don't expect it'll happen extremely soon due to my currently
    limited resources.

    On Tuesday, May 14, 2013 2:06:24 AM UTC-4, John Doe wrote:

    I meant that this would help during the coding phase, not the runtime.
    It's getting relatively timely to check, if the struct has the exact
    method with the exact signature, if they could all be declared in one place.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jimmy frasche at May 14, 2013 at 6:10 am
    You can also do this as a sort of static assert

    http://play.golang.org/p/a_BlvhHsx0

    However I think this is just something to get over. Interfaces are
    useful because you don't say who implements what. If you have a
    package that has, say, a lot of plugins that conform to some interface
    and you want it to be clear in the documentation that they're an X
    kind of plugin then just document that they're an X kind of plugin or
    make it part of the name.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at May 15, 2013 at 1:50 am
    I think we're mostly misinterpreting the OP's intent... He's not explicitly
    claiming that the interfaces declared to be implemented are the only ones a
    type can implement. Rather, the intent seems documentarian.

    There are several solutions to this issue:

        1. The convention in Go is to declare interface names based on method
        names (or on the composition of methods). A brief familiarization with the
        standard library interfaces will quickly allow you to identify the
        interfaces any type implements -- for example, if a type has a ReadAt
        method, you can generally assume it implements the io.ReaderAt interface
        (and it would be bad behavior on the author of the type if it does not
        conform to that interface).
        2. Tooling (including your editor), as mentioned by Dmitri. Outside of
        an editor, a specialized tool could be written to generate interface
        implementor lists.
        3. Instead of inventing new syntax, conventional use of comments can
        achieve the same, serving in part the same role that the api tool does.
    On Tuesday, May 14, 2013 12:01:15 AM UTC-6, andrey mirtchovski wrote:

    This has been discussed at least forever on the mailing list. The
    consensus is that rather than forcing everyone to explicitly state
    what they support, you can instead use the type system to verify it
    for them at runtime and at no extra clacking cost:

    http://play.golang.org/p/VmI9264X9q
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at May 15, 2013 at 1:51 am
    I think we're mostly misinterpreting the OP's intent... He's not explicitly
    claiming that the interfaces declared to be implemented are the only ones a
    type can implement. Rather, the intent seems documentarian.

    There are several solutions to this issue:

        1. The convention in Go is to declare interface names based on method
        names (or on the composition of methods). A brief familiarization with the
        standard library interfaces will quickly allow you to identify the
        interfaces any type implements -- for example, if a type has a ReadAt
        method, you can generally assume it implements the io.ReaderAt interface
        (and it would be bad behavior on the author of the type if it does not
        conform to that interface).
        2. Tooling (including your editor), as mentioned by Dmitri. Outside of
        an editor, a specialized tool could be written to generate interface
        implementor lists.
        3. Instead of inventing new syntax, conventional use of comments can
        achieve the same, serving in part the same role that the api tool does.
    On Tuesday, May 14, 2013 12:01:15 AM UTC-6, andrey mirtchovski wrote:

    This has been discussed at least forever on the mailing list. The
    consensus is that rather than forcing everyone to explicitly state
    what they support, you can instead use the type system to verify it
    for them at runtime and at no extra clacking cost:

    http://play.golang.org/p/VmI9264X9q
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • GreatOdinsRaven at May 14, 2013 at 6:32 pm
    This will never happen, not in Go. The missing "implements" is actually a
    feature, not an omission. It allows you to organically grow code without
    worrying about type hierarchies. It allows you to create interfaces when
    you need them and without having to do massive refactoring vs thinking
    about them up-front I believe you'll have better luck proposing the
    elimination of channels and adding C++-style generics.
    On Monday, May 13, 2013 11:56:32 PM UTC-6, John Doe wrote:

    My terminology might be off, but what i would like to see, would be
    interface usage declarations in struct definitions eq:

    type File struct : io.Reader, io.Writer {
    *file
    }

    This would make it clearer, what interfaces the struct has or is meant to
    implement and also aid in code generation.
    Currently i have to manually check all the methods on a struct to see, if
    it supports a given interface or not.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brendan Tracey at May 14, 2013 at 7:04 pm
    If it's just to check that it has all the right methods, you can just try
    to do a cast. It's a compile error if the cast does not work.
    http://play.golang.org/p/UMaScVTnoj

    If it's to see if one interface type is also another interface type, you
    can do that as well.
    http://play.golang.org/p/InYTI2XabZ

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 14, '13 at 5:56a
activeMay 15, '13 at 1:51a
posts11
users8
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase