FAQ
Is there a way to access the outer struct and its field from the embedded
struct? Should you pass the outer struct as a parameter?

--
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

  • Jsor at Dec 22, 2013 at 7:39 am
    So you're saying you have some setup like this:

    type A struct {
       x int
    }

    type B struct {
       A
       y int
    }

    And in some function you're given B.A, and want to access B from A? No, not
    really. That data isn't retained, your best best is to make A hold a
    pointer to its "owner".

    To be completely fair, you can do it using the unsafe package if you know
    the exact pointer offsets of the members of B you want to access, since
    structs are guaranteed to be laid out contiguously in memory in the order
    the fields are listed (at least I'm pretty sure), but that's going down a
    pretty dangerous road for obvious reasons.
    On Saturday, December 21, 2013 11:58:38 PM UTC-7, Peter Nguyen wrote:

    Is there a way to access the outer struct and its field from the embedded
    struct? Should you pass the outer struct as a parameter?
    --
    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.
  • Jsor at Dec 22, 2013 at 8:00 am


    To be completely fair, you can do it using the unsafe package if you know
    the exact pointer offsets of the members of B you want to access, since
    structs are guaranteed to be laid out contiguously in memory in the order
    the fields are listed (at least I'm pretty sure), but that's going down a
    pretty dangerous road for obvious reasons.
    Er, ignore this, that only works if you're given &B.A, not B.A itself by
    value. (Another reason this is a terrible idea).

    --
    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 Dec 22, 2013 at 7:54 am

    On Sun, Dec 22, 2013 at 5:58 PM, Peter Nguyen wrote:

    Is there a way to access the outer struct and its field from the embedded
    struct? Should you pass the outer struct as a parameter?
    Yes, you'll have to pass a pointer to the embedding struct to the embedded
    struct.
    But when people ask about this they are generally trying to fight the
    language and emulate inheritance.

    What problem are you trying to solve?


    --
    =====================
    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.
  • Peter Nguyen at Dec 22, 2013 at 8:10 am
    Yes, that's what I thought, a bad idea. I'm trying to create an abstract
    struct with common methods to be reused by other structs. How is the
    idiomatic way to do this?

    Den söndagen den 22:e december 2013 kl. 08:54:10 UTC+1 skrev Jesse McNelis:
    On Sun, Dec 22, 2013 at 5:58 PM, Peter Nguyen <peter.ng...@gmail.com<javascript:>
    wrote:
    Is there a way to access the outer struct and its field from the embedded
    struct? Should you pass the outer struct as a parameter?
    Yes, you'll have to pass a pointer to the embedding struct to the embedded
    struct.
    But when people ask about this they are generally trying to fight the
    language and emulate inheritance.

    What problem are you trying to solve?


    --
    =====================
    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.
  • Jsor at Dec 22, 2013 at 8:25 am
    If you already know that the methods on your embedded struct will require
    data in an exact format supplied by the embedding struct, why not just
    implement it on A? The only really "good" way I can think of to do this is
    to have an interface like this:

    type AEmbedder interface {
         SupplyData() TypeOfDataThatNeedsSupplying
    }

    And then your embedded type A can either accept an argument of type
    AEmbedder, or else have A hold a pointer to AEmbedder.

    The *better* way to do this is just to have functions that accept an
    interface that all your "derived" types happen to implement, and just leave
    out the embedding nonsense altogether.
    On Sunday, December 22, 2013 1:10:00 AM UTC-7, Peter Nguyen wrote:

    Yes, that's what I thought, a bad idea. I'm trying to create an abstract
    struct with common methods to be reused by other structs. How is the
    idiomatic way to do this?

    Den söndagen den 22:e december 2013 kl. 08:54:10 UTC+1 skrev Jesse McNelis:
    On Sun, Dec 22, 2013 at 5:58 PM, Peter Nguyen wrote:

    Is there a way to access the outer struct and its field from the
    embedded struct? Should you pass the outer struct as a parameter?
    Yes, you'll have to pass a pointer to the embedding struct to the
    embedded struct.
    But when people ask about this they are generally trying to fight the
    language and emulate inheritance.

    What problem are you trying to solve?


    --
    =====================
    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.
  • Egon at Dec 22, 2013 at 8:51 am

    On Sunday, December 22, 2013 10:10:00 AM UTC+2, Peter Nguyen wrote:
    Yes, that's what I thought, a bad idea. I'm trying to create an abstract
    struct with common methods to be reused by other structs. How is the
    idiomatic way to do this?
    Please tell the full story of what you are trying to accomplish. Currently
    you are just explaining methods, which help you do something.. but not what
    that something is.... and I just don't mean the concept of inheritance...
    are you working on a game, tcp protocol, website.... etc. The actual
    problem you are having! Otherwise you are going to get vague answers and a
    solution that may not actually solve your problem properly.

    Basically, the idiomatic way is not to do that... and to do something
    else... unless the other options even worse... which in case that would be
    the "best" way to do it.

    + egon


    Den söndagen den 22:e december 2013 kl. 08:54:10 UTC+1 skrev Jesse McNelis:
    On Sun, Dec 22, 2013 at 5:58 PM, Peter Nguyen wrote:

    Is there a way to access the outer struct and its field from the
    embedded struct? Should you pass the outer struct as a parameter?
    Yes, you'll have to pass a pointer to the embedding struct to the
    embedded struct.
    But when people ask about this they are generally trying to fight the
    language and emulate inheritance.

    What problem are you trying to solve?


    --
    =====================
    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.
  • Peter Nguyen at Dec 22, 2013 at 9:14 am
    Yes, I'm sorry, here is the full story. I'm working on a RESTful web
    application using one of the many go microframework. First I created a
    controller to one of the endpoints, let's call it /foos that has method to
    create, read, update, delete the entities. In the beginning, the DB logic
    was inside the methods of the controller, but when I have to create a
    second endpoint, let's call it /bars, it seemed necessary to abstract the
    DB logic to its own struct and methods. This worked quite well using object
    interface{} as parameter and pass on a pointer to the struct or passing the
    struct itself and do type assertion when you get it back.

    My next step now is trying to abstract the common methods of the
    controller, such as create, read, update, delete to a common struct, just
    as I did with the DB logic. Because most of the code for it is the same,
    except for the type of the struct that you're working with and its fields
    (such as DB table name, endpoint prefix etc.). As I'm new to Go, I wanted
    to try different approaches such as embedding to see if it was applicable
    to this problem.

    Den söndagen den 22:e december 2013 kl. 09:51:41 UTC+1 skrev egon:
    On Sunday, December 22, 2013 10:10:00 AM UTC+2, Peter Nguyen wrote:

    Yes, that's what I thought, a bad idea. I'm trying to create an abstract
    struct with common methods to be reused by other structs. How is the
    idiomatic way to do this?
    Please tell the full story of what you are trying to accomplish. Currently
    you are just explaining methods, which help you do something.. but not what
    that something is.... and I just don't mean the concept of inheritance...
    are you working on a game, tcp protocol, website.... etc. The actual
    problem you are having! Otherwise you are going to get vague answers and a
    solution that may not actually solve your problem properly.

    Basically, the idiomatic way is not to do that... and to do something
    else... unless the other options even worse... which in case that would be
    the "best" way to do it.

    + egon


    Den söndagen den 22:e december 2013 kl. 08:54:10 UTC+1 skrev Jesse
    McNelis:
    On Sun, Dec 22, 2013 at 5:58 PM, Peter Nguyen wrote:

    Is there a way to access the outer struct and its field from the
    embedded struct? Should you pass the outer struct as a parameter?
    Yes, you'll have to pass a pointer to the embedding struct to the
    embedded struct.
    But when people ask about this they are generally trying to fight the
    language and emulate inheritance.

    What problem are you trying to solve?


    --
    =====================
    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.
  • Egon at Dec 22, 2013 at 9:54 am
    mgo (http://labix.org/mgo) has a really good API for doing CRUD things, I
    think you can steal a lot from them. Maybe, something
    like https://gist.github.com/egonelbre/8080345... i.e. you still keep your
    structures in the Controller.

    Regarding the Controller... I think you are putting too much pressure on
    the Controller and it doesn't know yet what it wants to be... Read the
    Controller posts by Carlo Pescio,
    (http://www.carlopescio.com/2012/03/life-without-controller-case-1.html).
    Figure out how to name the parts and you'll probably get to a better
    solution. Depending on your application CQRS/DDD may suit better... i.e.
    CRUD approach usually couples together the querying and changing which can
    cause bottlenecks. Search for Greg Young videos for that.... but obviously,
    it will be a totally different architecture and it requires more to setup
    than the CRUD approach.

    I don't how much and how your structures differ, i.e. if the structures can
    be abstracted then the Controller and DB part will easily follow into a
    nicer abstraction. Of course you'll get dynamic structures then which could
    be problematic.

    But, you can also create a structure using the type of the structure... see
    the reflect package for
    that http://jimmyfrasche.github.io/go-reflection-codex/...
    e.g. http://play.golang.org/p/A1VZjNt-ua

    + egon
    On Sunday, December 22, 2013 11:14:43 AM UTC+2, Peter Nguyen wrote:

    Yes, I'm sorry, here is the full story. I'm working on a RESTful web
    application using one of the many go microframework. First I created a
    controller to one of the endpoints, let's call it /foos that has method to
    create, read, update, delete the entities. In the beginning, the DB logic
    was inside the methods of the controller, but when I have to create a
    second endpoint, let's call it /bars, it seemed necessary to abstract the
    DB logic to its own struct and methods. This worked quite well using object
    interface{} as parameter and pass on a pointer to the struct or passing the
    struct itself and do type assertion when you get it back.

    My next step now is trying to abstract the common methods of the
    controller, such as create, read, update, delete to a common struct, just
    as I did with the DB logic. Because most of the code for it is the same,
    except for the type of the struct that you're working with and its fields
    (such as DB table name, endpoint prefix etc.). As I'm new to Go, I wanted
    to try different approaches such as embedding to see if it was applicable
    to this problem.

    Den söndagen den 22:e december 2013 kl. 09:51:41 UTC+1 skrev egon:
    On Sunday, December 22, 2013 10:10:00 AM UTC+2, Peter Nguyen wrote:

    Yes, that's what I thought, a bad idea. I'm trying to create an abstract
    struct with common methods to be reused by other structs. How is the
    idiomatic way to do this?
    Please tell the full story of what you are trying to accomplish.
    Currently you are just explaining methods, which help you do something..
    but not what that something is.... and I just don't mean the concept of
    inheritance... are you working on a game, tcp protocol, website.... etc.
    The actual problem you are having! Otherwise you are going to get vague
    answers and a solution that may not actually solve your problem properly.

    Basically, the idiomatic way is not to do that... and to do something
    else... unless the other options even worse... which in case that would be
    the "best" way to do it.

    + egon


    Den söndagen den 22:e december 2013 kl. 08:54:10 UTC+1 skrev Jesse
    McNelis:
    On Sun, Dec 22, 2013 at 5:58 PM, Peter Nguyen wrote:

    Is there a way to access the outer struct and its field from the
    embedded struct? Should you pass the outer struct as a parameter?
    Yes, you'll have to pass a pointer to the embedding struct to the
    embedded struct.
    But when people ask about this they are generally trying to fight the
    language and emulate inheritance.

    What problem are you trying to solve?


    --
    =====================
    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.
  • Peter Nguyen at Dec 22, 2013 at 10:47 am
    Den söndagen den 22:e december 2013 kl. 10:54:40 UTC+1 skrev egon:
    mgo (http://labix.org/mgo) has a really good API for doing CRUD things, I
    think you can steal a lot from them. Maybe, something like
    https://gist.github.com/egonelbre/8080345... i.e. you still keep your
    structures in the Controller.
    My DB logic abstraction is like mgo, and fits pretty well so that's why I
    want to do the same for the controller part

    Regarding the Controller... I think you are putting too much pressure on
    the Controller and it doesn't know yet what it wants to be... Read the
    Controller posts by Carlo Pescio, (
    http://www.carlopescio.com/2012/03/life-without-controller-case-1.html).
    Figure out how to name the parts and you'll probably get to a better
    solution. Depending on your application CQRS/DDD may suit better... i.e.
    CRUD approach usually couples together the querying and changing which can
    cause bottlenecks. Search for Greg Young videos for that.... but obviously,
    it will be a totally different architecture and it requires more to setup
    than the CRUD approach.
    Thanks for the links, very interesting. The RESTful API fits well with CRUD
    though, so I don't think changing to CQRS will solves the problem. The
    responsibilities of the controllers right now is to unmarshalling data from
    JSON into structs and write to the response. I just want to abstract common
    code so that it is still DRY as I add more endpoints for the API. The
    methods that is not common will still stays in the individual controllers.

    I don't how much and how your structures differ, i.e. if the structures
    can be abstracted then the Controller and DB part will easily follow into a
    nicer abstraction. Of course you'll get dynamic structures then which could
    be problematic.
    The data model differs a lot between different entities (of course), but
    each controllers only differ in for example endpoint prefix (e.g. /foos or
    /bars) and the type of structs to unmarshalling data into.

    But, you can also create a structure using the type of the structure...
    see the reflect package for that
    http://jimmyfrasche.github.io/go-reflection-codex/... e.g.
    http://play.golang.org/p/A1VZjNt-ua
    I'm trying to avoid the reflect package if I can, it seems like the Swiss
    army knife for all kind of Go problems.

    + egon
    On Sunday, December 22, 2013 11:14:43 AM UTC+2, Peter Nguyen wrote:

    Yes, I'm sorry, here is the full story. I'm working on a RESTful web
    application using one of the many go microframework. First I created a
    controller to one of the endpoints, let's call it /foos that has method to
    create, read, update, delete the entities. In the beginning, the DB logic
    was inside the methods of the controller, but when I have to create a
    second endpoint, let's call it /bars, it seemed necessary to abstract the
    DB logic to its own struct and methods. This worked quite well using object
    interface{} as parameter and pass on a pointer to the struct or passing the
    struct itself and do type assertion when you get it back.

    My next step now is trying to abstract the common methods of the
    controller, such as create, read, update, delete to a common struct, just
    as I did with the DB logic. Because most of the code for it is the same,
    except for the type of the struct that you're working with and its fields
    (such as DB table name, endpoint prefix etc.). As I'm new to Go, I wanted
    to try different approaches such as embedding to see if it was applicable
    to this problem.

    Den söndagen den 22:e december 2013 kl. 09:51:41 UTC+1 skrev egon:
    On Sunday, December 22, 2013 10:10:00 AM UTC+2, Peter Nguyen wrote:

    Yes, that's what I thought, a bad idea. I'm trying to create an
    abstract struct with common methods to be reused by other structs. How is
    the idiomatic way to do this?
    Please tell the full story of what you are trying to accomplish.
    Currently you are just explaining methods, which help you do something..
    but not what that something is.... and I just don't mean the concept of
    inheritance... are you working on a game, tcp protocol, website.... etc.
    The actual problem you are having! Otherwise you are going to get vague
    answers and a solution that may not actually solve your problem properly.

    Basically, the idiomatic way is not to do that... and to do something
    else... unless the other options even worse... which in case that would be
    the "best" way to do it.

    + egon


    Den söndagen den 22:e december 2013 kl. 08:54:10 UTC+1 skrev Jesse
    McNelis:
    On Sun, Dec 22, 2013 at 5:58 PM, Peter Nguyen wrote:

    Is there a way to access the outer struct and its field from the
    embedded struct? Should you pass the outer struct as a parameter?
    Yes, you'll have to pass a pointer to the embedding struct to the
    embedded struct.
    But when people ask about this they are generally trying to fight the
    language and emulate inheritance.

    What problem are you trying to solve?


    --
    =====================
    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.
  • Egon at Dec 22, 2013 at 10:52 am

    On Sunday, December 22, 2013 12:47:16 PM UTC+2, Peter Nguyen wrote:


    Den söndagen den 22:e december 2013 kl. 10:54:40 UTC+1 skrev egon:
    mgo (http://labix.org/mgo) has a really good API for doing CRUD things,
    I think you can steal a lot from them. Maybe, something like
    https://gist.github.com/egonelbre/8080345... i.e. you still keep your
    structures in the Controller.
    My DB logic abstraction is like mgo, and fits pretty well so that's why I
    want to do the same for the controller part

    Regarding the Controller... I think you are putting too much pressure on
    the Controller and it doesn't know yet what it wants to be... Read the
    Controller posts by Carlo Pescio, (
    http://www.carlopescio.com/2012/03/life-without-controller-case-1.html).
    Figure out how to name the parts and you'll probably get to a better
    solution. Depending on your application CQRS/DDD may suit better... i.e.
    CRUD approach usually couples together the querying and changing which can
    cause bottlenecks. Search for Greg Young videos for that.... but obviously,
    it will be a totally different architecture and it requires more to setup
    than the CRUD approach.
    Thanks for the links, very interesting. The RESTful API fits well with
    CRUD though, so I don't think changing to CQRS will solves the problem. The
    responsibilities of the controllers right now is to unmarshalling data from
    JSON into structs and write to the response. I just want to abstract common
    code so that it is still DRY as I add more endpoints for the API. The
    methods that is not common will still stays in the individual controllers.

    I don't how much and how your structures differ, i.e. if the structures
    can be abstracted then the Controller and DB part will easily follow into a
    nicer abstraction. Of course you'll get dynamic structures then which could
    be problematic.
    The data model differs a lot between different entities (of course), but
    each controllers only differ in for example endpoint prefix (e.g. /foos or
    /bars) and the type of structs to unmarshalling data into.
    Then you could simply essentially skip using the structs and use a
    map[string]interface{} instead... and use some other field in Controller to
    define the types of each field. That would essentially flatten all your
    data and you can write your generic controller for that instead. It also
    gives the benefit of being able to define new controllers at runtime.

    But, you can also create a structure using the type of the structure...
    see the reflect package for that
    http://jimmyfrasche.github.io/go-reflection-codex/... e.g.
    http://play.golang.org/p/A1VZjNt-ua
    I'm trying to avoid the reflect package if I can, it seems like the Swiss
    army knife for all kind of Go problems.

    + egon
    On Sunday, December 22, 2013 11:14:43 AM UTC+2, Peter Nguyen wrote:

    Yes, I'm sorry, here is the full story. I'm working on a RESTful web
    application using one of the many go microframework. First I created a
    controller to one of the endpoints, let's call it /foos that has method to
    create, read, update, delete the entities. In the beginning, the DB logic
    was inside the methods of the controller, but when I have to create a
    second endpoint, let's call it /bars, it seemed necessary to abstract the
    DB logic to its own struct and methods. This worked quite well using object
    interface{} as parameter and pass on a pointer to the struct or passing the
    struct itself and do type assertion when you get it back.

    My next step now is trying to abstract the common methods of the
    controller, such as create, read, update, delete to a common struct, just
    as I did with the DB logic. Because most of the code for it is the same,
    except for the type of the struct that you're working with and its fields
    (such as DB table name, endpoint prefix etc.). As I'm new to Go, I wanted
    to try different approaches such as embedding to see if it was applicable
    to this problem.

    Den söndagen den 22:e december 2013 kl. 09:51:41 UTC+1 skrev egon:
    On Sunday, December 22, 2013 10:10:00 AM UTC+2, Peter Nguyen wrote:

    Yes, that's what I thought, a bad idea. I'm trying to create an
    abstract struct with common methods to be reused by other structs. How is
    the idiomatic way to do this?
    Please tell the full story of what you are trying to accomplish.
    Currently you are just explaining methods, which help you do something..
    but not what that something is.... and I just don't mean the concept of
    inheritance... are you working on a game, tcp protocol, website.... etc.
    The actual problem you are having! Otherwise you are going to get vague
    answers and a solution that may not actually solve your problem properly.

    Basically, the idiomatic way is not to do that... and to do something
    else... unless the other options even worse... which in case that would be
    the "best" way to do it.

    + egon


    Den söndagen den 22:e december 2013 kl. 08:54:10 UTC+1 skrev Jesse
    McNelis:
    On Sun, Dec 22, 2013 at 5:58 PM, Peter Nguyen wrote:

    Is there a way to access the outer struct and its field from the
    embedded struct? Should you pass the outer struct as a parameter?
    Yes, you'll have to pass a pointer to the embedding struct to the
    embedded struct.
    But when people ask about this they are generally trying to fight the
    language and emulate inheritance.

    What problem are you trying to solve?


    --
    =====================
    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.
  • Peter Nguyen at Dec 22, 2013 at 1:00 pm
    I think I solved my problem by defining a "config" struct with the
    different attributes for each endpoint
    (http://play.golang.org/p/LcLKZPlcPU). This should enable for a generic
    controller with the common methods. The advantage of using structs instead
    of map[string]interface{} is that when unmarshalling, I get data type check
    and filter which is very convenient.

    Den söndagen den 22:e december 2013 kl. 11:52:45 UTC+1 skrev egon:

    On Sunday, December 22, 2013 12:47:16 PM UTC+2, Peter Nguyen wrote:



    Den söndagen den 22:e december 2013 kl. 10:54:40 UTC+1 skrev egon:
    mgo (http://labix.org/mgo) has a really good API for doing CRUD things,
    I think you can steal a lot from them. Maybe, something like
    https://gist.github.com/egonelbre/8080345... i.e. you still keep your
    structures in the Controller.
    My DB logic abstraction is like mgo, and fits pretty well so that's why I
    want to do the same for the controller part

    Regarding the Controller... I think you are putting too much pressure on
    the Controller and it doesn't know yet what it wants to be... Read the
    Controller posts by Carlo Pescio, (
    http://www.carlopescio.com/2012/03/life-without-controller-case-1.html).
    Figure out how to name the parts and you'll probably get to a better
    solution. Depending on your application CQRS/DDD may suit better... i.e.
    CRUD approach usually couples together the querying and changing which can
    cause bottlenecks. Search for Greg Young videos for that.... but obviously,
    it will be a totally different architecture and it requires more to setup
    than the CRUD approach.
    Thanks for the links, very interesting. The RESTful API fits well with
    CRUD though, so I don't think changing to CQRS will solves the problem. The
    responsibilities of the controllers right now is to unmarshalling data from
    JSON into structs and write to the response. I just want to abstract common
    code so that it is still DRY as I add more endpoints for the API. The
    methods that is not common will still stays in the individual controllers.

    I don't how much and how your structures differ, i.e. if the structures
    can be abstracted then the Controller and DB part will easily follow into a
    nicer abstraction. Of course you'll get dynamic structures then which could
    be problematic.
    The data model differs a lot between different entities (of course), but
    each controllers only differ in for example endpoint prefix (e.g. /foos or
    /bars) and the type of structs to unmarshalling data into.
    Then you could simply essentially skip using the structs and use a
    map[string]interface{} instead... and use some other field in Controller to
    define the types of each field. That would essentially flatten all your
    data and you can write your generic controller for that instead. It also
    gives the benefit of being able to define new controllers at runtime.

    But, you can also create a structure using the type of the structure...
    see the reflect package for that
    http://jimmyfrasche.github.io/go-reflection-codex/... e.g.
    http://play.golang.org/p/A1VZjNt-ua
    I'm trying to avoid the reflect package if I can, it seems like the Swiss
    army knife for all kind of Go problems.

    + egon
    On Sunday, December 22, 2013 11:14:43 AM UTC+2, Peter Nguyen wrote:

    Yes, I'm sorry, here is the full story. I'm working on a RESTful web
    application using one of the many go microframework. First I created a
    controller to one of the endpoints, let's call it /foos that has method to
    create, read, update, delete the entities. In the beginning, the DB logic
    was inside the methods of the controller, but when I have to create a
    second endpoint, let's call it /bars, it seemed necessary to abstract the
    DB logic to its own struct and methods. This worked quite well using object
    interface{} as parameter and pass on a pointer to the struct or passing the
    struct itself and do type assertion when you get it back.

    My next step now is trying to abstract the common methods of the
    controller, such as create, read, update, delete to a common struct, just
    as I did with the DB logic. Because most of the code for it is the same,
    except for the type of the struct that you're working with and its fields
    (such as DB table name, endpoint prefix etc.). As I'm new to Go, I wanted
    to try different approaches such as embedding to see if it was applicable
    to this problem.

    Den söndagen den 22:e december 2013 kl. 09:51:41 UTC+1 skrev egon:
    On Sunday, December 22, 2013 10:10:00 AM UTC+2, Peter Nguyen wrote:

    Yes, that's what I thought, a bad idea. I'm trying to create an
    abstract struct with common methods to be reused by other structs. How is
    the idiomatic way to do this?
    Please tell the full story of what you are trying to accomplish.
    Currently you are just explaining methods, which help you do something..
    but not what that something is.... and I just don't mean the concept of
    inheritance... are you working on a game, tcp protocol, website.... etc.
    The actual problem you are having! Otherwise you are going to get vague
    answers and a solution that may not actually solve your problem properly.

    Basically, the idiomatic way is not to do that... and to do something
    else... unless the other options even worse... which in case that would be
    the "best" way to do it.

    + egon


    Den söndagen den 22:e december 2013 kl. 08:54:10 UTC+1 skrev Jesse
    McNelis:
    On Sun, Dec 22, 2013 at 5:58 PM, Peter Nguyen <peter.ng...@gmail.com
    wrote:
    Is there a way to access the outer struct and its field from the
    embedded struct? Should you pass the outer struct as a parameter?
    Yes, you'll have to pass a pointer to the embedding struct to the
    embedded struct.
    But when people ask about this they are generally trying to fight
    the language and emulate inheritance.

    What problem are you trying to solve?


    --
    =====================
    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.
  • Egon at Dec 22, 2013 at 1:49 pm
    To me it seems you are still storing too much info in the controller... I
    would try to separate out the database/table logic into some Repo/Table,
    and give that as a parameter to the controller. I.e. the controller
    shouldn't know where the objects live.
    e.g. http://play.golang.org/p/_RCvgcrygM

    Btw. have you already looked at revel and martini?

    + egon
    On Sunday, December 22, 2013 3:00:00 PM UTC+2, Peter Nguyen wrote:

    I think I solved my problem by defining a "config" struct with the
    different attributes for each endpoint (
    http://play.golang.org/p/LcLKZPlcPU). This should enable for a generic
    controller with the common methods. The advantage of using structs instead
    of map[string]interface{} is that when unmarshalling, I get data type check
    and filter which is very convenient.

    Den söndagen den 22:e december 2013 kl. 11:52:45 UTC+1 skrev egon:

    On Sunday, December 22, 2013 12:47:16 PM UTC+2, Peter Nguyen wrote:



    Den söndagen den 22:e december 2013 kl. 10:54:40 UTC+1 skrev egon:
    mgo (http://labix.org/mgo) has a really good API for doing CRUD
    things, I think you can steal a lot from them. Maybe, something like
    https://gist.github.com/egonelbre/8080345... i.e. you still keep your
    structures in the Controller.
    My DB logic abstraction is like mgo, and fits pretty well so that's why
    I want to do the same for the controller part

    Regarding the Controller... I think you are putting too much pressure
    on the Controller and it doesn't know yet what it wants to be... Read the
    Controller posts by Carlo Pescio, (
    http://www.carlopescio.com/2012/03/life-without-controller-case-1.html).
    Figure out how to name the parts and you'll probably get to a better
    solution. Depending on your application CQRS/DDD may suit better... i.e.
    CRUD approach usually couples together the querying and changing which can
    cause bottlenecks. Search for Greg Young videos for that.... but obviously,
    it will be a totally different architecture and it requires more to setup
    than the CRUD approach.
    Thanks for the links, very interesting. The RESTful API fits well with
    CRUD though, so I don't think changing to CQRS will solves the problem. The
    responsibilities of the controllers right now is to unmarshalling data from
    JSON into structs and write to the response. I just want to abstract common
    code so that it is still DRY as I add more endpoints for the API. The
    methods that is not common will still stays in the individual controllers.

    I don't how much and how your structures differ, i.e. if the structures
    can be abstracted then the Controller and DB part will easily follow into a
    nicer abstraction. Of course you'll get dynamic structures then which could
    be problematic.
    The data model differs a lot between different entities (of course), but
    each controllers only differ in for example endpoint prefix (e.g. /foos or
    /bars) and the type of structs to unmarshalling data into.
    Then you could simply essentially skip using the structs and use a
    map[string]interface{} instead... and use some other field in Controller to
    define the types of each field. That would essentially flatten all your
    data and you can write your generic controller for that instead. It also
    gives the benefit of being able to define new controllers at runtime.

    But, you can also create a structure using the type of the structure...
    see the reflect package for that
    http://jimmyfrasche.github.io/go-reflection-codex/... e.g.
    http://play.golang.org/p/A1VZjNt-ua
    I'm trying to avoid the reflect package if I can, it seems like the
    Swiss army knife for all kind of Go problems.

    + egon
    On Sunday, December 22, 2013 11:14:43 AM UTC+2, Peter Nguyen wrote:

    Yes, I'm sorry, here is the full story. I'm working on a RESTful web
    application using one of the many go microframework. First I created a
    controller to one of the endpoints, let's call it /foos that has method to
    create, read, update, delete the entities. In the beginning, the DB logic
    was inside the methods of the controller, but when I have to create a
    second endpoint, let's call it /bars, it seemed necessary to abstract the
    DB logic to its own struct and methods. This worked quite well using object
    interface{} as parameter and pass on a pointer to the struct or passing the
    struct itself and do type assertion when you get it back.

    My next step now is trying to abstract the common methods of the
    controller, such as create, read, update, delete to a common struct, just
    as I did with the DB logic. Because most of the code for it is the same,
    except for the type of the struct that you're working with and its fields
    (such as DB table name, endpoint prefix etc.). As I'm new to Go, I wanted
    to try different approaches such as embedding to see if it was applicable
    to this problem.

    Den söndagen den 22:e december 2013 kl. 09:51:41 UTC+1 skrev egon:
    On Sunday, December 22, 2013 10:10:00 AM UTC+2, Peter Nguyen wrote:

    Yes, that's what I thought, a bad idea. I'm trying to create an
    abstract struct with common methods to be reused by other structs. How is
    the idiomatic way to do this?
    Please tell the full story of what you are trying to accomplish.
    Currently you are just explaining methods, which help you do something..
    but not what that something is.... and I just don't mean the concept of
    inheritance... are you working on a game, tcp protocol, website.... etc.
    The actual problem you are having! Otherwise you are going to get vague
    answers and a solution that may not actually solve your problem properly.

    Basically, the idiomatic way is not to do that... and to do something
    else... unless the other options even worse... which in case that would be
    the "best" way to do it.

    + egon


    Den söndagen den 22:e december 2013 kl. 08:54:10 UTC+1 skrev Jesse
    McNelis:
    On Sun, Dec 22, 2013 at 5:58 PM, Peter Nguyen <
    peter.ng...@gmail.com> wrote:
    Is there a way to access the outer struct and its field from the
    embedded struct? Should you pass the outer struct as a parameter?
    Yes, you'll have to pass a pointer to the embedding struct to the
    embedded struct.
    But when people ask about this they are generally trying to fight
    the language and emulate inheritance.

    What problem are you trying to solve?


    --
    =====================
    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.
  • Peter Nguyen at Dec 22, 2013 at 2:04 pm
    The DB logic is already separated into a DBService. So some methods in my
    controllers now only requires one line:

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

    Yes, Revel is too big for a REST API and I'm using gocraft/web instead of
    Martini for the router


    Den söndagen den 22:e december 2013 kl. 14:49:27 UTC+1 skrev egon:
    To me it seems you are still storing too much info in the controller... I
    would try to separate out the database/table logic into some Repo/Table,
    and give that as a parameter to the controller. I.e. the controller
    shouldn't know where the objects live. e.g.
    http://play.golang.org/p/_RCvgcrygM

    Btw. have you already looked at revel and martini?

    + egon
    On Sunday, December 22, 2013 3:00:00 PM UTC+2, Peter Nguyen wrote:

    I think I solved my problem by defining a "config" struct with the
    different attributes for each endpoint (
    http://play.golang.org/p/LcLKZPlcPU). This should enable for a generic
    controller with the common methods. The advantage of using structs instead
    of map[string]interface{} is that when unmarshalling, I get data type check
    and filter which is very convenient.

    Den söndagen den 22:e december 2013 kl. 11:52:45 UTC+1 skrev egon:

    On Sunday, December 22, 2013 12:47:16 PM UTC+2, Peter Nguyen wrote:



    Den söndagen den 22:e december 2013 kl. 10:54:40 UTC+1 skrev egon:
    mgo (http://labix.org/mgo) has a really good API for doing CRUD
    things, I think you can steal a lot from them. Maybe, something like
    https://gist.github.com/egonelbre/8080345... i.e. you still keep your
    structures in the Controller.
    My DB logic abstraction is like mgo, and fits pretty well so that's why
    I want to do the same for the controller part

    Regarding the Controller... I think you are putting too much pressure
    on the Controller and it doesn't know yet what it wants to be... Read the
    Controller posts by Carlo Pescio, (
    http://www.carlopescio.com/2012/03/life-without-controller-case-1.html).
    Figure out how to name the parts and you'll probably get to a better
    solution. Depending on your application CQRS/DDD may suit better... i.e.
    CRUD approach usually couples together the querying and changing which can
    cause bottlenecks. Search for Greg Young videos for that.... but obviously,
    it will be a totally different architecture and it requires more to setup
    than the CRUD approach.
    Thanks for the links, very interesting. The RESTful API fits well with
    CRUD though, so I don't think changing to CQRS will solves the problem. The
    responsibilities of the controllers right now is to unmarshalling data from
    JSON into structs and write to the response. I just want to abstract common
    code so that it is still DRY as I add more endpoints for the API. The
    methods that is not common will still stays in the individual controllers.

    I don't how much and how your structures differ, i.e. if the
    structures can be abstracted then the Controller and DB part will easily
    follow into a nicer abstraction. Of course you'll get dynamic structures
    then which could be problematic.
    The data model differs a lot between different entities (of course),
    but each controllers only differ in for example endpoint prefix (e.g. /foos
    or /bars) and the type of structs to unmarshalling data into.
    Then you could simply essentially skip using the structs and use a
    map[string]interface{} instead... and use some other field in Controller to
    define the types of each field. That would essentially flatten all your
    data and you can write your generic controller for that instead. It also
    gives the benefit of being able to define new controllers at runtime.

    But, you can also create a structure using the type of the
    structure... see the reflect package for that
    http://jimmyfrasche.github.io/go-reflection-codex/... e.g.
    http://play.golang.org/p/A1VZjNt-ua
    I'm trying to avoid the reflect package if I can, it seems like the
    Swiss army knife for all kind of Go problems.

    + egon
    On Sunday, December 22, 2013 11:14:43 AM UTC+2, Peter Nguyen wrote:

    Yes, I'm sorry, here is the full story. I'm working on a RESTful web
    application using one of the many go microframework. First I created a
    controller to one of the endpoints, let's call it /foos that has method to
    create, read, update, delete the entities. In the beginning, the DB logic
    was inside the methods of the controller, but when I have to create a
    second endpoint, let's call it /bars, it seemed necessary to abstract the
    DB logic to its own struct and methods. This worked quite well using object
    interface{} as parameter and pass on a pointer to the struct or passing the
    struct itself and do type assertion when you get it back.

    My next step now is trying to abstract the common methods of the
    controller, such as create, read, update, delete to a common struct, just
    as I did with the DB logic. Because most of the code for it is the same,
    except for the type of the struct that you're working with and its fields
    (such as DB table name, endpoint prefix etc.). As I'm new to Go, I wanted
    to try different approaches such as embedding to see if it was applicable
    to this problem.

    Den söndagen den 22:e december 2013 kl. 09:51:41 UTC+1 skrev egon:
    On Sunday, December 22, 2013 10:10:00 AM UTC+2, Peter Nguyen wrote:

    Yes, that's what I thought, a bad idea. I'm trying to create an
    abstract struct with common methods to be reused by other structs. How is
    the idiomatic way to do this?
    Please tell the full story of what you are trying to accomplish.
    Currently you are just explaining methods, which help you do something..
    but not what that something is.... and I just don't mean the concept of
    inheritance... are you working on a game, tcp protocol, website.... etc.
    The actual problem you are having! Otherwise you are going to get vague
    answers and a solution that may not actually solve your problem properly.

    Basically, the idiomatic way is not to do that... and to do
    something else... unless the other options even worse... which in case that
    would be the "best" way to do it.

    + egon


    Den söndagen den 22:e december 2013 kl. 08:54:10 UTC+1 skrev Jesse
    McNelis:
    On Sun, Dec 22, 2013 at 5:58 PM, Peter Nguyen <
    peter.ng...@gmail.com> wrote:
    Is there a way to access the outer struct and its field from the
    embedded struct? Should you pass the outer struct as a parameter?
    Yes, you'll have to pass a pointer to the embedding struct to the
    embedded struct.
    But when people ask about this they are generally trying to fight
    the language and emulate inheritance.

    What problem are you trying to solve?


    --
    =====================
    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.
  • Jesse McNelis at Dec 22, 2013 at 9:11 am

    On Sun, Dec 22, 2013 at 7:10 PM, Peter Nguyen wrote:

    Yes, that's what I thought, a bad idea. I'm trying to create an abstract
    struct with common methods to be reused by other structs. How is the
    idiomatic way to do this?
    The idiomatic way to do this is to write those methods as functions that
    take interface parameters and have the other structs implement those
    interfaces.


    --
    =====================
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedDec 22, '13 at 6:58a
activeDec 22, '13 at 2:04p
posts15
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase