Sharing info between structures in golang
I have a general handler that contains the data it needs to do all it has to do.
type Handler struct {
info HandlerInfo
}
Then the sender struct, which equally has its own information.
type Sender struct {
info SenderInfo
}
Finally, there's a receiver, that also has its own information.
type Receiver struct {
info ReceiverInfo
}
The handler generates communicating pairs along the execution of the program. I don't wanna give examples of the type of communication that occurs between the different structures I have defined since I want my example to be the broadest possible.
func (h Handler) Do() {
for /* something happens */ {
sender := Sender{}
receiver := Receiver{}
}
sender.DoSomething()
if sender.ShouldSend() {
receiver.Receive()
}
}
Everything looks quite simple up to here but I'm facing two issues :
1) How to handle the data being shared by Sender and Receiver without redundancy?
2) How to handle the data that's used by Handler but that Sender and Receiver also need to use?
1) How to handle the data being shared by Sender and Receiver without redundancy?
One might say it's only necessary to fill both structures step by step with what they're going to need
But it makes things too much redundant IMO:
func DoSomethingAndFill() {
data1 := generateSomeData1()
recv.Receive1(data1)
sender.Send1(data1)
data2 := generateSomeData2()
recv.Receive2(data2)
sender.Send2(data2)
}
I told myself I could (litterally) share a base structure containing the data that needs to be shared :
type MetaData struct {
Data1 Data
Data2 Data
}
type Sender struct {
*MetaData
info SenderInfo
}
type Receiver struct {
*MetaData
info ReceiverInfo
}
And when initializing I only needed to put the same pointer?
func init() {
md := MetaData{}
recv, send := Receiver{&md}, Sender{&md}
}
But this forces me to do two things :
On one hand if I want to make things clean and make a package for Receiver and another one for Sender, I have to make all fields of MetaData exported, which, while not being dramatically bad, is not ideal.
On the other hand, I'm forced to make the code a little more confusing since when filling the structure I have to juggle between what goes into Sender, Receiver and MetaData.
2) How to handle the data that's used by Handler but that Sender and Receiver also need to use?
This first thing that came to my mind was to make a sort of backward link to the parent structure :
type Handler struct {
Info HandlerInfo
}
type Sender struct {
handler Handler
info SenderInfo
}
type Receiver struct {
handler Handler
info ReceiverInfo
}
func (h Handler) MakeRecvAndSend() {
recv, send := Receiver{
handler: h,
}, Sender{
handler: h,
}
}
And at first sight it seems quite good, but again, if Sender and Receiver are in different packages, and since circular imports are not permitted in Golang, it is not possible.
Another solution I thought of would be to copy the relevant information piece by piece:
type Handler struct {
info1 HandlerInfo
info2 HandlerInfo
}
type Sender struct {
handlerInfo HandlerInfo
info SenderInfo
}
type Receiver struct {
handlerInfo HanlderInfo
info ReceiverInfo
}
func (h Handler) MakeRecvAndSend() {
recv, send := Receiver{
handlerInfo: h.info1,
}, Sender{
handler: h.info2,
}
}
But this is reaaaally verbose, and according to the way I generate senders and receivers I'm afraid this is going to impact runtime speed / memory.
If you already ran into such issues, I'd like your feedback and the way you solved this. I'm also interesting in any theoretical thought you might want to share!
Thx!
algorithm go refactoring structure
asked Nov 25 '18 at 16:25
MichelMichel
61
add a comment |
I have a general handler that contains the data it needs to do all it has to do.
type Handler struct {
info HandlerInfo
}
Then the sender struct, which equally has its own information.
type Sender struct {
info SenderInfo
}
Finally, there's a receiver, that also has its own information.
type Receiver struct {
info ReceiverInfo
}
The handler generates communicating pairs along the execution of the program. I don't wanna give examples of the type of communication that occurs between the different structures I have defined since I want my example to be the broadest possible.
func (h Handler) Do() {
for /* something happens */ {
sender := Sender{}
receiver := Receiver{}
}
sender.DoSomething()
if sender.ShouldSend() {
receiver.Receive()
}
}
Everything looks quite simple up to here but I'm facing two issues :
1) How to handle the data being shared by Sender and Receiver without redundancy?
2) How to handle the data that's used by Handler but that Sender and Receiver also need to use?
1) How to handle the data being shared by Sender and Receiver without redundancy?
One might say it's only necessary to fill both structures step by step with what they're going to need
But it makes things too much redundant IMO:
func DoSomethingAndFill() {
data1 := generateSomeData1()
recv.Receive1(data1)
sender.Send1(data1)
data2 := generateSomeData2()
recv.Receive2(data2)
sender.Send2(data2)
}
I told myself I could (litterally) share a base structure containing the data that needs to be shared :
type MetaData struct {
Data1 Data
Data2 Data
}
type Sender struct {
*MetaData
info SenderInfo
}
type Receiver struct {
*MetaData
info ReceiverInfo
}
And when initializing I only needed to put the same pointer?
func init() {
md := MetaData{}
recv, send := Receiver{&md}, Sender{&md}
}
But this forces me to do two things :
On one hand if I want to make things clean and make a package for Receiver and another one for Sender, I have to make all fields of MetaData exported, which, while not being dramatically bad, is not ideal.
On the other hand, I'm forced to make the code a little more confusing since when filling the structure I have to juggle between what goes into Sender, Receiver and MetaData.
2) How to handle the data that's used by Handler but that Sender and Receiver also need to use?
This first thing that came to my mind was to make a sort of backward link to the parent structure :
type Handler struct {
Info HandlerInfo
}
type Sender struct {
handler Handler
info SenderInfo
}
type Receiver struct {
handler Handler
info ReceiverInfo
}
func (h Handler) MakeRecvAndSend() {
recv, send := Receiver{
handler: h,
}, Sender{
handler: h,
}
}
And at first sight it seems quite good, but again, if Sender and Receiver are in different packages, and since circular imports are not permitted in Golang, it is not possible.
Another solution I thought of would be to copy the relevant information piece by piece:
type Handler struct {
info1 HandlerInfo
info2 HandlerInfo
}
type Sender struct {
handlerInfo HandlerInfo
info SenderInfo
}
type Receiver struct {
handlerInfo HanlderInfo
info ReceiverInfo
}
func (h Handler) MakeRecvAndSend() {
recv, send := Receiver{
handlerInfo: h.info1,
}, Sender{
handler: h.info2,
}
}
But this is reaaaally verbose, and according to the way I generate senders and receivers I'm afraid this is going to impact runtime speed / memory.
If you already ran into such issues, I'd like your feedback and the way you solved this. I'm also interesting in any theoretical thought you might want to share!
Thx!
algorithm go refactoring structure
asked Nov 25 '18 at 16:25
MichelMichel
61
5
I have to admit I do not understand what you are trying to do and where the problem is.
– Volker
Nov 25 '18 at 17:03
I'm refactoring a project and in a much practical way, I am trying to find out the best solution to handle this pattern of a general handler creating child structures, their data being shared in some ways that make it complicated to have a clear schema. But I realized the problem is much broader than juste my tiny project and it can be generalized to what I wrote here. What are the unclear points for you?
– Michel
Nov 25 '18 at 17:16
1
What kind of app is this? Is this a web app? I've never seen this "pattern" before, so I can't really provide suggestions without more context.
– Flimzy
Nov 25 '18 at 18:32
would making all the Handler/Sender/Receiver complying with a common interface definition let them share "common data" in the way you want?
– Vorsprung
Nov 25 '18 at 20:26
add a comment |
I have a general handler that contains the data it needs to do all it has to do.
type Handler struct {
info HandlerInfo
}
Then the sender struct, which equally has its own information.
type Sender struct {
info SenderInfo
}
Finally, there's a receiver, that also has its own information.
type Receiver struct {
info ReceiverInfo
}
The handler generates communicating pairs along the execution of the program. I don't wanna give examples of the type of communication that occurs between the different structures I have defined since I want my example to be the broadest possible.
func (h Handler) Do() {
for /* something happens */ {
sender := Sender{}
receiver := Receiver{}
}
sender.DoSomething()
if sender.ShouldSend() {
receiver.Receive()
}
}
Everything looks quite simple up to here but I'm facing two issues :
1) How to handle the data being shared by Sender and Receiver without redundancy?
2) How to handle the data that's used by Handler but that Sender and Receiver also need to use?
1) How to handle the data being shared by Sender and Receiver without redundancy?
One might say it's only necessary to fill both structures step by step with what they're going to need
But it makes things too much redundant IMO:
func DoSomethingAndFill() {
data1 := generateSomeData1()
recv.Receive1(data1)
sender.Send1(data1)
data2 := generateSomeData2()
recv.Receive2(data2)
sender.Send2(data2)
}
I told myself I could (litterally) share a base structure containing the data that needs to be shared :
type MetaData struct {
Data1 Data
Data2 Data
}
type Sender struct {
*MetaData
info SenderInfo
}
type Receiver struct {
*MetaData
info ReceiverInfo
}
And when initializing I only needed to put the same pointer?
func init() {
md := MetaData{}
recv, send := Receiver{&md}, Sender{&md}
}
But this forces me to do two things :
On one hand if I want to make things clean and make a package for Receiver and another one for Sender, I have to make all fields of MetaData exported, which, while not being dramatically bad, is not ideal.
On the other hand, I'm forced to make the code a little more confusing since when filling the structure I have to juggle between what goes into Sender, Receiver and MetaData.
2) How to handle the data that's used by Handler but that Sender and Receiver also need to use?
This first thing that came to my mind was to make a sort of backward link to the parent structure :
type Handler struct {
Info HandlerInfo
}
type Sender struct {
handler Handler
info SenderInfo
}
type Receiver struct {
handler Handler
info ReceiverInfo
}
func (h Handler) MakeRecvAndSend() {
recv, send := Receiver{
handler: h,
}, Sender{
handler: h,
}
}
And at first sight it seems quite good, but again, if Sender and Receiver are in different packages, and since circular imports are not permitted in Golang, it is not possible.
Another solution I thought of would be to copy the relevant information piece by piece:
type Handler struct {
info1 HandlerInfo
info2 HandlerInfo
}
type Sender struct {
handlerInfo HandlerInfo
info SenderInfo
}
type Receiver struct {
handlerInfo HanlderInfo
info ReceiverInfo
}
func (h Handler) MakeRecvAndSend() {
recv, send := Receiver{
handlerInfo: h.info1,
}, Sender{
handler: h.info2,
}
}
But this is reaaaally verbose, and according to the way I generate senders and receivers I'm afraid this is going to impact runtime speed / memory.
If you already ran into such issues, I'd like your feedback and the way you solved this. I'm also interesting in any theoretical thought you might want to share!
Thx!
algorithm go refactoring structure
asked Nov 25 '18 at 16:25
MichelMichel
61
I have a general handler that contains the data it needs to do all it has to do.
type Handler struct {
info HandlerInfo
}
Then the sender struct, which equally has its own information.
type Sender struct {
info SenderInfo
}
Finally, there's a receiver, that also has its own information.
type Receiver struct {
info ReceiverInfo
}
The handler generates communicating pairs along the execution of the program. I don't wanna give examples of the type of communication that occurs between the different structures I have defined since I want my example to be the broadest possible.
func (h Handler) Do() {
for /* something happens */ {
sender := Sender{}
receiver := Receiver{}
}
sender.DoSomething()
if sender.ShouldSend() {
receiver.Receive()
}
}
Everything looks quite simple up to here but I'm facing two issues :
1) How to handle the data being shared by Sender and Receiver without redundancy?
2) How to handle the data that's used by Handler but that Sender and Receiver also need to use?
1) How to handle the data being shared by Sender and Receiver without redundancy?
One might say it's only necessary to fill both structures step by step with what they're going to need
But it makes things too much redundant IMO:
func DoSomethingAndFill() {
data1 := generateSomeData1()
recv.Receive1(data1)
sender.Send1(data1)
data2 := generateSomeData2()
recv.Receive2(data2)
sender.Send2(data2)
}
I told myself I could (litterally) share a base structure containing the data that needs to be shared :
type MetaData struct {
Data1 Data
Data2 Data
}
type Sender struct {
*MetaData
info SenderInfo
}
type Receiver struct {
*MetaData
info ReceiverInfo
}
And when initializing I only needed to put the same pointer?
func init() {
md := MetaData{}
recv, send := Receiver{&md}, Sender{&md}
}
But this forces me to do two things :
On one hand if I want to make things clean and make a package for Receiver and another one for Sender, I have to make all fields of MetaData exported, which, while not being dramatically bad, is not ideal.
On the other hand, I'm forced to make the code a little more confusing since when filling the structure I have to juggle between what goes into Sender, Receiver and MetaData.
2) How to handle the data that's used by Handler but that Sender and Receiver also need to use?
This first thing that came to my mind was to make a sort of backward link to the parent structure :
type Handler struct {
Info HandlerInfo
}
type Sender struct {
handler Handler
info SenderInfo
}
type Receiver struct {
handler Handler
info ReceiverInfo
}
func (h Handler) MakeRecvAndSend() {
recv, send := Receiver{
handler: h,
}, Sender{
handler: h,
}
}
And at first sight it seems quite good, but again, if Sender and Receiver are in different packages, and since circular imports are not permitted in Golang, it is not possible.
Another solution I thought of would be to copy the relevant information piece by piece:
type Handler struct {
info1 HandlerInfo
info2 HandlerInfo
}
type Sender struct {
handlerInfo HandlerInfo
info SenderInfo
}
type Receiver struct {
handlerInfo HanlderInfo
info ReceiverInfo
}
func (h Handler) MakeRecvAndSend() {
recv, send := Receiver{
handlerInfo: h.info1,
}, Sender{
handler: h.info2,
}
}
But this is reaaaally verbose, and according to the way I generate senders and receivers I'm afraid this is going to impact runtime speed / memory.
If you already ran into such issues, I'd like your feedback and the way you solved this. I'm also interesting in any theoretical thought you might want to share!
Thx!
algorithm go refactoring structure
algorithm go refactoring structure
asked Nov 25 '18 at 16:25
MichelMichel
61
asked Nov 25 '18 at 16:25
MichelMichel
61
edited Nov 25 '18 at 17:18
Michel
asked Nov 25 '18 at 16:25
MichelMichel
61
asked Nov 25 '18 at 16:25
MichelMichel
61
asked Nov 25 '18 at 16:25
MichelMichel
61
61
5
I have to admit I do not understand what you are trying to do and where the problem is.
– Volker
Nov 25 '18 at 17:03
I'm refactoring a project and in a much practical way, I am trying to find out the best solution to handle this pattern of a general handler creating child structures, their data being shared in some ways that make it complicated to have a clear schema. But I realized the problem is much broader than juste my tiny project and it can be generalized to what I wrote here. What are the unclear points for you?
– Michel
Nov 25 '18 at 17:16
1
What kind of app is this? Is this a web app? I've never seen this "pattern" before, so I can't really provide suggestions without more context.
– Flimzy
Nov 25 '18 at 18:32
would making all the Handler/Sender/Receiver complying with a common interface definition let them share "common data" in the way you want?
– Vorsprung
Nov 25 '18 at 20:26
add a comment |
5
I have to admit I do not understand what you are trying to do and where the problem is.
– Volker
Nov 25 '18 at 17:03
I'm refactoring a project and in a much practical way, I am trying to find out the best solution to handle this pattern of a general handler creating child structures, their data being shared in some ways that make it complicated to have a clear schema. But I realized the problem is much broader than juste my tiny project and it can be generalized to what I wrote here. What are the unclear points for you?
– Michel
Nov 25 '18 at 17:16
1
What kind of app is this? Is this a web app? I've never seen this "pattern" before, so I can't really provide suggestions without more context.
– Flimzy
Nov 25 '18 at 18:32
would making all the Handler/Sender/Receiver complying with a common interface definition let them share "common data" in the way you want?
– Vorsprung
Nov 25 '18 at 20:26
5
5
I have to admit I do not understand what you are trying to do and where the problem is.
– Volker
Nov 25 '18 at 17:03
I have to admit I do not understand what you are trying to do and where the problem is.
– Volker
Nov 25 '18 at 17:03
I'm refactoring a project and in a much practical way, I am trying to find out the best solution to handle this pattern of a general handler creating child structures, their data being shared in some ways that make it complicated to have a clear schema. But I realized the problem is much broader than juste my tiny project and it can be generalized to what I wrote here. What are the unclear points for you?
– Michel
Nov 25 '18 at 17:16
I'm refactoring a project and in a much practical way, I am trying to find out the best solution to handle this pattern of a general handler creating child structures, their data being shared in some ways that make it complicated to have a clear schema. But I realized the problem is much broader than juste my tiny project and it can be generalized to what I wrote here. What are the unclear points for you?
– Michel
Nov 25 '18 at 17:16
1
1
What kind of app is this? Is this a web app? I've never seen this "pattern" before, so I can't really provide suggestions without more context.
– Flimzy
Nov 25 '18 at 18:32
What kind of app is this? Is this a web app? I've never seen this "pattern" before, so I can't really provide suggestions without more context.
– Flimzy
Nov 25 '18 at 18:32
would making all the Handler/Sender/Receiver complying with a common interface definition let them share "common data" in the way you want?
– Vorsprung
Nov 25 '18 at 20:26
would making all the Handler/Sender/Receiver complying with a common interface definition let them share "common data" in the way you want?
– Vorsprung
Nov 25 '18 at 20:26
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53469493%2fsharing-info-between-structures-in-golang%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53469493%2fsharing-info-between-structures-in-golang%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
5
I have to admit I do not understand what you are trying to do and where the problem is.
– Volker
Nov 25 '18 at 17:03
I'm refactoring a project and in a much practical way, I am trying to find out the best solution to handle this pattern of a general handler creating child structures, their data being shared in some ways that make it complicated to have a clear schema. But I realized the problem is much broader than juste my tiny project and it can be generalized to what I wrote here. What are the unclear points for you?
– Michel
Nov 25 '18 at 17:16
1
What kind of app is this? Is this a web app? I've never seen this "pattern" before, so I can't really provide suggestions without more context.
– Flimzy
Nov 25 '18 at 18:32
would making all the Handler/Sender/Receiver complying with a common interface definition let them share "common data" in the way you want?
– Vorsprung
Nov 25 '18 at 20:26