> > I think that we should use API generation (templating) for testing, not > only for enums but also for new traversal methods and such. If a new method > doesn't have an equivalent in a GLV, an explicit condition must be added, > that way we can make sure we don't miss GLV implementations on API changes.
Wouldn't GLV tests catch such things? Presumably a new aspect of the API would always have GLV tests to cover the newly available feature? Let's say we want the extra coverage and safety though - how would what you propose work exactly? We'd generate the API somewhere temporary and then somehow compare that to what we were maintaining manually? Could you explain what you have in mind a bit further? On Mon, Jun 22, 2020 at 7:38 AM Jorge Bay Gondra <[email protected]> wrote: > Sorry for being so late in the discussion, I've missed this discussion > originally and I saw it through the ticket TINKERPOP-2385. > > I agree that GLV templating makes it harder for new non-jvm contributors to > learn the codebase and understand how it works. +1 on dropping it > to generate GLV APIs. > > I think that we should use API generation (templating) for testing, not > only for enums but also for new traversal methods and such. If a new method > doesn't have an equivalent in a GLV, an explicit condition must be added, > that way we can make sure we don't miss GLV implementations on API changes. > > > On Wed, Jun 3, 2020 at 9:43 PM Stephen Mallette <[email protected]> > wrote: > > > We generated GLVs with templates based on Groovy scripts and bound that > > into Maven so that changes to Java would immediately and automatically > > generate into the GLVs. We also did it that way to avoid a lot of typing > in > > the initial creation of the GLVs as a lot of it is a bit boilerplate. Of > > course, now that the GLVs we have are established I wonder if the > > complexity that we have around the templates is still necessary. > > > > 1. The reality is that when Gremlin changes the code generation is only > of > > help if the alternation is minor. More often, it means adding to the > > already complex templates and scripting system. > > 2. The templating system seems to confuse non-JVM developers who look to > > contribute to the GLVs. > > 3. We now have the GLV test suite which we didn't have when we started. > The > > code generation was helpful because it ensured that the language stayed > in > > synch and that we didn't leave out a step or token. It's arguable that we > > don't need that anymore since the test suite would capture such failures. > > > > Perhaps the best use of code generation right now would be with keeping > the > > Enums in synch as the test suite may not cover all of those - of course > > that might point to a gap in testing. We could say that going forward all > > enums must be under test. > > > > I think this could be a chance for a good change in 3.5.0 to simplify the > > build a bit and drop the use of the template system going forward. If > this > > is a bad idea for some reason, then what might we do to make the > templating > > system better and easier to maintain? > > > > > -- > Jorge Bay Gondra > e. [email protected] > w. www.datastax.com >
