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
