mbeckerle commented on a change in pull request #422:
URL: https://github.com/apache/incubator-daffodil/pull/422#discussion_r498430401
##########
File path:
daffodil-core/src/main/scala/org/apache/daffodil/grammar/GrammarTerm.scala
##########
@@ -51,7 +52,8 @@ import org.apache.daffodil.dsom.Term
abstract class Gram(contextArg: SchemaComponent)
extends OOLAGHostImpl(contextArg)
with BasicComponent
- with GramRuntime1Mixin {
+ with GramRuntime1Mixin
+ with GramRuntime2Mixin {
Review comment:
Well, by way of discussion..... bunch of points here.
So one issue is that runtime2 isn't independent of runtime1. I believe there
are things created when runtime1 creates the parsers and unparsers that are
used by runtime2.
There's also a hypothesis here, that the backends could be pluggable because
the schema compiler doesn't have to do backend-specific things. The schema
compiler has a backend-independent aspect, which creates and hooks together the
grammar objects. But the implementation of the grammar objects is the _essence_
of the back-end.
A back end is (a) the part of the schema compiler (grammar objects) that
create data structures for that back end, and (b) a library of primitives.
Part (a) here is part of daffodil-core pretty much inherently right now.
Grammar primitives use all the data structures of the schema compiler - the
DSOM objects are available, and used as context for issuing SDEs from the
grammar objects
Part (b) is the daffodil-runtimeX module. For runtime2 right now this is a
tiny thing currently, but would of course grow rapidly as we expand beyond just
32-bit integers.
Every backend is going to add code to the grammar primitives. Right now
those grammar primitives support 3 methods that backends implement.
parser/unparser which create scala data structures that are invocable to carry
out parsing/unparsing, and now generateCode, which carries out a generation
processes, and like parser/unparser can cause SDEs to be issued, but otherwise
is sort of the end of the line for the compiler.
If we wanted to separate backends in a pluggable way, from the rest of the
schema compiler, I think the grammar objects would not have
parser/unparser/code-generator methods on them at all. Instead the grammar data
structure would be the output of the schema compiler. The back-end
implementation of each grammar primitive's compilation would be found and
delegated to, or maybe the grammar data structure would be walked/visited by a
separate back-end specific compiler pass.
The challenge with this refactoring is doing it without having to
reimplement an echo of each grammar object class in each back-end.
Object-oriented Mixins are tightly coupling everything together, but
minimize this delegation and walker kind of "glue logic" which makes code so
tedious to maintain.
Given that runtime2 depends on runtime1 currently, this didn't seem worth it
as of yet.
----------------------------------------------------------------
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]
