yes, though I would hope someone would lead with such information if they were somehow working with some extension of TinkerrGraph. ugh - you're kinda reminding me why we stuck to our guns and haven't allowed this sort of thing for all these years.
On Fri, Sep 11, 2020 at 9:32 AM Kelvin Lawrence <[email protected]> wrote: > Ah got it. My imagination ran a bit wild there envisioning something > bigger than just extending classes. Makes sense. So the only real concern I > would have is when we get bug reports that we ask “did you extend any of > the classes?” > > On 2020/09/11 10:42:24 Stephen Mallette wrote: > > > "my query fails on Graph DB XYZ but works on unmodified TinkerGraph" > > > > I can't remember if that was another concern or not, but note that I may > > not have been clear - the intention isn't to make it so TinkerGraph can > > take extensions by way of plugins but by allowing folks to extend from > the > > various Java classes that TinkerGraph exposes (which are all currently > > marked as "final"). So "extensible" really just means class inheritance > in > > the classic object-oriented definition. Perhaps that additional context > > answers your other questions. > > > > On Thu, Sep 10, 2020 at 6:44 PM Kelvin Lawrence <[email protected] > > > > wrote: > > > > > In general if people see a need for an extensible TinkerGraph and want > to > > > avoid making forks it seems a reasonable ask. My only slight concern > might > > > be that we lose the strong likelihood that when a user says something > like > > > "my query fails on Graph DB XYZ but works on unmodified TinkerGraph" > that > > > there is an issue with the other implementation has or at least some > > > conscious deviation from the "reference implementation". So we will > have to > > > get used to asking "have you applied any extensions?". Other than > that, if > > > people have good use cases for wanting to extend TinkerGraph I can't > think > > > of other reasons right now to say it is a bad idea. > > > > > > Would the extension mechanism you envisage allow for graph providers to > > > customize TinkerGraph to better mirror their implementation's behavior > - > > > without needing to fork it? In one case I can think of, perhaps a > provider > > > does not support all Gremlin steps yet for some reason but wants to > enable > > > easy development and testing using TinkerGraph for their users. Or > would > > > you perhaps see that as violating the API contract that final was used > to > > > protect? > > > > > > On 2020/09/10 11:33:07, Stephen Mallette <[email protected]> wrote: > > > > Should TinkerGraph be extendable? This is not a new discussion. Most> > > > > notably, Michael Pollmeier long ago wanted to allow for this to> > > > > experiment with a TinkerGraph fork where he used schemas to > drastically> > > > > increase the performance:> > > > > > > > > https://github.com/ShiftLeftSecurity/tinkergraph-gremlin> > > > > > > > > which then was replaced by the quite neat:> > > > > > > > > https://github.com/ShiftLeftSecurity/overflowdb> > > > > > > > > To the best of my knowledge, the argument against making TinkerGraph> > > > > extendable has been that allowing extension of TinkerGraph would > create> > > > > situations where we felt we couldn't alter TinkerGraph APIs and > > > behaviors> > > > > as easily as we would like and wanted to maintain the flexibility to > > > change> > > > > what we wanted when we wanted without fear of breaking those > extending > > > it.> > > > > > > > > Since those early discussions to come to that reasoning many years > ago,> > > > > I've learned that TinkerGraph has a lot of interesting usages that > you> > > > > normally wouldn't think of. I've seen/heard it used internally within > > > graph> > > > > systems quite regularly. This might be for testing or functional > > > purposes> > > > > and there are times when being able to extend it would be quite handy > > > where> > > > > a fork of TinkerGraph would be too heavy handed. I've also come to > the> > > > > realization that in our current times, TinkerGraph is quite stable in > > > terms> > > > > of API and behavior (the two things we've wanted to protect with > > > "final"> > > > > modifiers). There are few changes, the last major one probably > relates > > > to> > > > > the introduction of null support in 3.5.0 almost 12 months ago.> > > > > > > > > Given these realizations and another recent request to "remove a > final" > > > in> > > > > TinkerGraph, I've started to wonder if the reasons we had many years > > > ago> > > > > still hold and am inclined to think that they do not. Does anyone > have> > > > > thoughts on the matter?> > > > > > > > > As an aside, it's interesting that when a project lives long enough, > > > the> > > > > decisions that felt like absolutes begin to feel a bit more mutable. > > > For> > > > > example, for years we thought we'd never maintain Gremlin in other> > > > > languages in our repository, but now we hold many languages here and > > > GLVs> > > > > are highly popular in what they allow. Sorta thought provoking....> > > > > > > > Cheers, > > > Kelvin > > > > > > > > > > > > > > > Cheers, Kelvin > >
