[go-nuts] Question about embedding

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.

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

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?

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:

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.

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

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:

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

Den söndagen den 22:e december 2013 kl. 10:54:40 UTC+1 skrev egon:
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

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.

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.

I'm trying to avoid the reflect package if I can, it seems like the Swiss
army knife for all kind of Go problems.

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.

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:

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

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:

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.