> > 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?
Good point, we have good coverage on the GLV test suite and any new API surface will require new Gherkin features, causing a failure in the build if not handled by a GLV. It looks like we can safely get rid of the templating system. On Tue, Jun 23, 2020 at 4:55 PM Stephen Mallette <[email protected]> wrote: > > > > 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 > > >
