Do you have a plan to support abstract class?
I'd like to use masking feature even in abstract class (or sealed abstract class) and I know if this library only supports case class.
Do you have a plan to support it in this library?
@kenchan0130 Do you mean something like:
@customize
abstract class RootClass
case class Child(@mask field: String)
?
@kciesielski
For example,
@customize
sealed abstract class RootClass(@mask val value: String)
case object Child1 extends RootClass("child1")
case object Child2 extends RootClass("child2")
like this.
I see, thanks. An interesting case, I'll try to look into implementing it. What kind of data do you store in the "value" field? I'm asking because I'm curious what needs to be masked from toString which is, at the same time, hardcoded in the sources.
I'm so sorry. That example was not concrete.
trait SomeLibraryTrait[T] {
val value: T
override def toString() = value.toString()
}
@customize
abstract class EmployeePrivateInfo(@mask val value: Int) extends SomeLibraryTrait[Int]
case object Bachelor extends EmployeePrivateInfo(1)
case object AlreadyMarried extends EmployeePrivateInfo(2)
Specifically, it is here.
Suppose that SomeLibraryTrait is an uncontrolled trait provided by a library and so on.
Certainly, I can also create custom trait with masking string like:
trait MaskTrait[T] extends SomeLibraryTrait[T] {
override val value: T
override def toString() = "*****"
}
// Without using stringmask library
abstract class EmployeePrivateInfo(val value: Int) extends MaskTrait[Int]
case object Bachelor extends EmployeePrivateInfo(1)
case object AlreadyMarried extends EmployeePrivateInfo(2)
I see, but still the masked values 1 and 2 are hardcoded. What business case can be modeled with hardcoded constant values which need to be masked in toString? Are these some keys or other kinds of identifiers?
I have the case I want to mask in a complex situation.
In the case where it is important personal information when two items are combined, I want to mask some strings For example,
case class Employee(name: EmployeeName, privateInfo: EmployeePrivateInfo)
Of course, because of the different responsibilities, there may be some opinion that it should be marked on the upper layer like:
@customize
case class Employee(name: EmployeeName, @mask privateInfo: EmployeePrivateInfo)
However, in this case, some developers may forget to mask value because EmployeePrivateInfo is not primitive value.
Thanks for explaining. I can see how supporting abstract classes fits to this case. I will look into supporting abstract classes.