Removes the optionality in Coproducts

[rafaparadela]

This PR fixes #113

It converts the TOption values within TCoproduct into TRequired.

[BeniVF]

Hey @rafaparadela, are we transforming from TOption to TRequired for all the cases? If that's so, why don't we remove TOption from the Protobuf tree? If it is posible, we can avoid this transformation, can't
we?

[rafaparadela]

Not really. We are just removing the optionality in coproducts, but we might want to remain the options in the rest of the cases.

[SemanticBeeng]

Not really. We are just removing the optionality in coproducts, but we might want to remain the options in the rest of the cases.

Thanks for the PR.
Agreed to above point and was wondering if there are ways to control this from options somehow - thought I saw code suggesting the possibility. 🤔

Always related to https://github.com/julien-lafont/protoless and its motivation - "protobuf is not your domain model" - and always feel the need to control the mapping to the more rich domain model. (relates to #91)

[rafaparadela]

I totally agree with your statement "always feel the need to control the mapping to the more rich domain model", but I believe that the original purpose of this library was providing the mechanisms to transform protocols into a canonical IDL without losing information and tending to preserve the nature of the original schema.

It's great to have this debate, and thanks for bringing it up.

I think that Skeuomorph should keep being accurate when interpreting the schemas (whatever IDL). If there are not required fields in Proto 3, that is to say, all fields are "optional", then the transformation from Proto 3 to Scala must be sensitive to this circumstance, by using the scala Option.

On the other hand, there are strategies that users can follow to express the nullability of a field, to differentiate when a field is missing to preserve backward compatibility or when explicitly a field must be null to express lack to value.

Proto2

message Foo {
    optional int32 bar = 1;
}

Here, behind the field bar there is a semantic which denotes nullability.

Proto3

message Foo {
   int32 bar = 1;
}

Here, bar is optional perse, but not nullable. I mean, if the value is not provided, does not fail, but we don't really know if this lack comes from legacy clients that do not know the existence of the field bar, or explicitly they want to emit a null value.

But we can express this nullability semantic by:

message Foo {
  oneof bar {
    bool bar_null = 1; 
    int32 bar_value = 2;
  }
}

In my last PR, we are omitting the redundant optionality within coproducts because just adds complexity, nothing else.

Actually, we used to have some optimization in these cases, where Skeuomorph was able to detect when the user is attempting to express this nullability, and the coproduct was transformed into Option or Either.

In summary, I'm inclined to keep interpreting the Protobuf fields as properties within the scala-option.

[SemanticBeeng]

Thank you. Agreed with this thought process as well.

"strategies that users can follow to express"

Quite interested to learn about how to express those as user ofmu (or of skeuomorph from mu) as well as in skeuomorph standalone.

At this point am using mu and would like to both transform the schema to avoid handcrafting classes I can avoid but also (ideally) create the marshallers for the actual runtime (not in scope of skeuomorph right?).

Made some comments about marshalling in the latter part of #91 (comment).

[BeniVF]

LGTM