Let’s say I have a TypedStruct that has some common fields:
@typedoc "A product."
This is a product and because products can go on sale, I have another TypedStruct:
@typedoc "A sale."
Now, you are probably seeing there is some duplication here. Since a sale is a product with extra info, some of the fields are replicated.
A first attempt at a solution could be something like this:
@typedoc "A sale."
However, my use case does not allow for this. I must have a struct with exactly the same fields as
Product.t() and a few extra. I cannot simply smash a
product field into my sales struct.
- Is there a way to compose types using TypedStruct (or normal structs?)
- If not, what do you think would be the solution with the least amount of copy/pasting for this issue?
Are you saying a sale contains a product (1)? Or is a sale something completely different from a product(2)?
If (2): They’re not the same so don’t try to do as if they’re the same.
In case of (1): I’m really interested as for why you can’t do what you proposed with product as part of sale?
I would go for (1). A sale is not a product, but contains one.
I can’t follow the proposed solution because the generated Json file would not be compatible with the API I am integrating with.
I think the cleanest solution would be to write a custom encoder for the product: Jason.Encoder — jason v1.4.0
Although I would not mind this kind of duplication either.
It really depends on the domain and what sale and products are exactly.
That sounds like you‘re missing a translation layer between your internal data model and the outside world.
Yes, that is the thing I am trying to build
Would you go for duplication, for an implementation of the Jason encode protocol, or something else?
I’d go for the simplest to change option for things outside of your control, which would likely be duplication. Don’t try to abstract something other people are in charge off.