Support for sealed traits

[PerWiklander]

Use case: Exhaustive pattern matching of related domain events.

A file level option like:
option (scalapb.message).sealedTrait = "DomainEvent";

This would cause all messages in the .proto file to be put in the same .scala file along with a
sealed trait DomainEvent {}

[thesamet]

I wonder if it makes sense to automatically have all the messages in the file extend the sealed trait, or individual messages should be opted in via option (scalapb.message).extends

[PerWiklander]

Consider that it is a sealed trait and all extending messages have to be generated in the same .scala file. It would be confusing if only some of the messages from a .proto end up in the same file and others in separate files.

At least in my use case it would require copy+pasting option (scalapb.message).extends into every message of the file.

[trungfinity]

Do you have any plan to implement this?

[thesamet]

See example usage in : https://github.com/trueaccord/ScalaPB/blob/master/e2e/src/main/protobuf/sealed_trait.proto

[PerWiklander]

In your example the sealed trait in the preamble has methods prefixed with get, getFoo and getBar. Is that required? And does it even work with the generated case class, which I assume would have public vals named foo and bar?

[PerWiklander]

Or was that just an example? I guess my initial example for this issue doesn't require any defs on the sealed trait, since it's just a grouping trait for pattern matching.

[thesamet]

It's just an example. You can leave the sealed trait empty. There's no
requirement to define anything in it.

On Fri, Apr 15, 2016, 5:26 AM Per Wiklander notifications@github.com
wrote:

Or was that just an example? I guess my initial example for this issue
doesn't require any defs on the sealed trait, since it's just a grouping
trait for pattern matching.

—
You are receiving this because you modified the open/close state.

Reply to this email directly or view it on GitHub
#67 (comment)

[ngbinh]

thanks! This is great!