<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hello Rémi,</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">> 
The solution is known as type class (see [1] for type class in Scala 3) sadly Java does not support them (yet ?).<br></div><div class="gmail_default" style="font-family:monospace">> [1] <a href="https://docs.scala-lang.org/scala3/book/ca-type-classes.html">https://docs.scala-lang.org/scala3/book/ca-type-classes.html</a>

</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Thank you for introducing me to Scala 3 Type classes. The concept sounds very similar to interfaces with unimplemented methods, but I assume that they don't just restrict this to instance methods like Java does?<br></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">> Another solution is to switch on classes with</div><div class="gmail_default" style="font-family:monospace">> <br></div><div class="gmail_default" style="font-family:monospace">> Class<? extends Parseable> parseableType = (...) Parseable.class.getPermittedSubclasses();<br><div>> switch(parseableType) {<br></div><div>>     case Identifier.class -> ...</div><div>>     case Type.class -> ...<br></div><div>>     // etc<br></div><div>> }<br></div><div>> <br></div><div>> Here because Parseable is sealed, the compiler knows all the classes so can do an exhaustive checks, sadly Java does not support them too.</div>

</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">I actually thought of this too myself. I was very disappointed to discover that it's not possible.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">> 
So if we can not use the compiler, the best is to write unit tests that 
will check that there is a field named "regex" of type pattern on all 
subclasses and also checks that the is a unit test for each subclasses 
that check the string format (by doing reflection) on the unit tests. 
The idea is to replace the checks you would like the compiler does for 
you by unit tests that ensure that everything follow the "meta-protocol"
 you have defined.

</div><div class="gmail_default" style="font-family:monospace">
<div class="gmail_default" style="font-family:monospace">> <br></div><div class="gmail_default" style="font-family:monospace">> 
By doing the reflection in the tests instead of in the main code avoid 
to make the main code slow and you can also check that the test coverage
 is good.

</div>

</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">I definitely agree that it will improve performance. For this project, I think I will leave the reflection in the code for now, but I agree that any future projects that force me to use reflection to enforce a standard should have all reflection limited to unit tests.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">That said, I am still bothered by the fact that I am forced to depend on reflection. Maybe I am wrong for feeling this way, but reflection feels like using a second-class solution to solve a first-class problem. And I say second-class because it feels like I am throwing out type-safety at so many points, forcing me to operate on assumptions instead. For example, when calling the Class::getConstructor, I have to pass in a parameter of List.class to represent my List<String> constructors. Java doesn't allow me to pass in List<String>.class (understandably). But if I later refactor my code to take in a List<SomeFoo> instead, this method will still compile just fine, and won't fail until I try to use it during runtime. That would put me right back into the same pit that I used reflection to get myself out of. In order for me to get totality/exhaustiveness, I must give up type-safety. It feels like a bad trade. I actually ran into this exact problem during one of my refactors. I managed to get around this by using even more reflection combined with some hard coded dummy values, but that feels even worse.<br></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">I wish the language gave me some way to test my parameter against all of the permitted subclasses, see which one succeeds, then return the match (ideally as a newly created instance), all without giving up the type-safety and totality that I've had up until that point. Apologies for repeating myself, I am only using this to demonstrate what I feel a first class solution would look like.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Thank you so much for your response and insight!</div><div class="gmail_default" style="font-family:monospace">David Alayachew<br></div></div></div>