stevedlawrence commented on a change in pull request #394:
URL: https://github.com/apache/incubator-daffodil/pull/394#discussion_r455915070
##########
File path: daffodil-japi/src/main/scala/org/apache/daffodil/japi/Daffodil.scala
##########
@@ -373,6 +374,12 @@ class ProcessorFactory private[japi] (private var pf:
SProcessorFactory)
new DataProcessor(dp)
}
+ /**
+ * Exposes the RootView object corresponding to this ProcessorFactory. This
can
+ * be used to start a walk using the walkFromRoot method in a DSOM Walker.
+ */
+ def rootView: RootView = pf.rootView
Review comment:
I know the Scala language sometimes uses an ``experimental`` object that
things go in, so we could do something like that:
```scala
class ProcoessorFactory(pf: SProcessorFactory) {
...
object experimental {
def rootView: RootView = pf.rootView
}
...
}
```
To access the rootView, one would do something like this:
```scala
val rootView = pf.experimental.rootView
```
That makes it very obvious when you are using something that is experimental
and that the API might change in the future. If we do go this route, I wonder
if it also make sense to create a new sbt subproject and move all the new View
traits and AbstratDSOMWalker in an experimental package (eg.
org.apache.daffodil.experimental.dsom.walker), similar to how we have the
daffodil-udf package split out? And we can use the new unidoc stuff to include
it in public API docs?
Not sure how I feel about this though. Maybe it's too obtrusive?
I think the other option is to just have a blurb like "This API is
experimental is and subject to change". I don't know if there's an annotation
or standard javadoc practice for this kind of thing.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
