Ah. I get it now. A code generator only needs this processor stuff to leverage the TDML framework. Other than that it doesn't get used in this API model at all.
Makes sense. No need to implement DFDLProcessor. On Tue, Feb 7, 2023 at 5:55 PM Interrante, John A (GE Research, US) < john.interra...@ge.com> wrote: > No, I don't propose to create one class implementing both DFDLProcessor > and TDMLDFDLProcessor. I'm asserting that a code generator doesn't need to > implement DFDLProcessor. In about 1-2 years of use, we have found zero > callers interested in calling the C code generator's DFDLProcessor > implementation from Scala or Java (other than TDML Runner). > > A code generator needs to implement only TDMLDFDLProcessor and that's all > TDML Runner needs to get TDML tests working. If a caller ever wants to run > the compiled executable and get a parse result from it, they can simply > call the TDMLDFDLProcessor implementation. The semantics are pretty > equivalent, only with TDML prefixed to the names. That's my rationale for > the simplification. > > John > > -----Original Message----- > From: Mike Beckerle <mbecke...@apache.org> > Sent: Tuesday, February 7, 2023 1:57 PM > To: dev@daffodil.apache.org > Subject: EXT: Re: Discussion about merging Runtime2DataProcessor.scala > into Runtime2TDMLDFDLProcessor.scala > > What you are suggesting sounds reasonable to me. > > So the point of the base TDMLDFDProcessor was to enable us to create a > TDML processor from IBM DFDL (or other DFDL processors) for the IBM Cross > Tester rig. It's supposed to be the minimal interface that will let our > TDML runner drive a DFDL implementation. > > If you want to create one class that implements both DFDLProcessor and > TDMLDFDLProcessor that makes sense to me. > > Scala-wise, I'm not sure how it works if you inherit the same method > signature from more than one trait, that is I'm not sure if you can > implement it once and satisfy both traits. If that's a problem maybe > DFDLProcesor needs to inherit from TDMLDFDLProcessor, so those signatures > exist in exactly one trait? > > -mikeb > > > On Mon, Feb 6, 2023 at 1:47 PM Interrante, John A (GE Research, US) < > john.interra...@ge.com> wrote: > > > I want to merge Runtime2DataProcessor.scala into > > Runtime2TDMLDFDLProcessor.scala since doing so will reduce codegen-c's > > number of lines of code and number of classes. My experience writing > > a TDMLDFDProcessor for another code generator (not released yet) and > > writing unit tests for it has shown me that the > > Runtime2TDMLDFDLProcessor and Runtime2DataProcessor are the same from > > a caller's point of view. Either way, the caller has to call > > compileCode, get the executable file's path, call "new > > Runtime2TDMLDFDLProcessor(executable)" or "new > > Runtime2DataProcessor(executable)" to get a processor object, and then > > call its parse method with arguments. The parse result object is the > > same too, just wrapped in a TDMLParseResult class if it comes from > Runtime2TDMLDFDLProcessor. > > > > I assert that both unit tests and the TDML Runner are the only pieces > > of Java/Scala software that will ever generate code from a DFDL > > schema, build an executable, call that executable, and return a parse > > result. I can type "daffodil generate c -s <schema>" commands and use > > the C code without involving any other Java/Scala code. I can type or > > script "make -C c" and "c/daffodil parse -o out in" commands for more > > automation too. I also can type "daffodil test -I daffodilC <tdml>" > > commands or run TestXXX.scala classes which call a Runner object, > > which are the only times I've ever needed to run the C executable from > Java/Scala. > > > > I'd like to dispense with two such similar APIs. Instead of wrapping > > the TDML API around the Processor API, I'd like to implement the TDML > > API directly with no underlying Processor API needed. I assert that > > code generators don't need to provide a processor object API (no need > > to implement a getProcessor() method and a DataProcessor API). Code > > generators only need to provide a TDMLDFDLProcessorFactory for the > > TDML Runner to use. If any new future Java/Scala callers do come > > along, they can call "new Runtime2TDMLDFDLProcessor(executable)" to > > get a processor object with the same functionality as "new > > Runtime2DataProcessor(executable)" anyway. > > > > Any thoughts about or objections to merging > > Runtime2DataProcessor.scala into Runtime2TDMLDFDLProcessor.scala? I > > will merge the classes in a separate PR from a PR renaming > > daffodil-runtime2 to daffodil-codegen-c to make reviewing each PR easier. > > > > John > > > > >
