mbeckerle commented on code in PR #1122:
URL: https://github.com/apache/daffodil/pull/1122#discussion_r1418027465
##########
daffodil-japi/src/main/scala/org/apache/daffodil/japi/Daffodil.scala:
##########
@@ -141,7 +141,6 @@ class Compiler private[japi] (private var sCompiler:
SCompiler) {
): ProcessorFactory = {
val pf = sCompiler.compileFile(schemaFile, Option(rootName),
Option(rootNamespace))
- pf.isError
new ProcessorFactory(pf)
Review Comment:
I think the pattern for getting rid of this wrapper stuff is to have a
java-usable abstract base/interface defined in a ".java" file, that has all the
methods the Java API user would need to call including static factory methods.
This ".java" file also has all the javadoc.
Then the scala implementation derives its actual classes from that
base/interface, and those can all use scala types and such. Then the "API" for
java users is just returning the object, upcasted to the java base/interface
that shows only the java-usable methods.
This doesn't prevent the Java user from just downcasting and using something
internal, but I think the whole wrapper approach, which does prevent the
downcasting bypass, is just not worth the maintenance headache. Plus this is
open source, so what are we really preventing anyway?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
