Hi guys, I just finalized TinkerGraph. The problem is that I don't want to be stuck having to keep TinkerGraph "as is" if people extend its classes. With GraphMutator coming in 3.1+, TinkerGraph internals will change. Finally, Titan was relying on TinkerGraph's Memory and MapReduce engine -- that would freeze TinkerGraph to always use those method, code. I have since copied the code over to Titan so Titan has a clone of the TinkerGraph Memory/MapReduce engine.
In TinkerPop2, we have had problems with people extending TinkerGraph --- its just hand cuffs I don't want to be stuck with. Hope that is cool, Marko. http://markorodriguez.com On May 20, 2015, at 2:10 AM, Bryn Cooke <[email protected]> wrote: > This problem reminds me of the checkstyle rule: > http://checkstyle.sourceforge.net/config_design.html#DesignForExtension > > Could it be possible to determine which classes are likely to be subclassed > and add explicit extension points? > > Bryn > > > > On 20/05/15 06:56, pieter-gmail wrote: >> I am less of a fan for using final. >> >> For some future client it often turns a trivial solution using inheritance >> into a big discussion. >> Sometimes the final is removed and other times a big engineering feat is >> required to keep it and solve the clients problem. >> >> 2 cents, >> Pieter >> >> On 19/05/2015 23:59, Marko A. Rodriguez (JIRA) wrote: >>> Marko A. Rodriguez created TINKERPOP3-692: >>> --------------------------------------------- >>> >>> Summary: Should we final TinkerGraph? >>> Key: TINKERPOP3-692 >>> URL: https://issues.apache.org/jira/browse/TINKERPOP3-692 >>> Project: TinkerPop 3 >>> Issue Type: Improvement >>> Reporter: Marko A. Rodriguez >>> Fix For: 3.0.0.GA >>> >>> >>> If we are going to make TinkerGraph's classes final, we should do it before >>> GA. I'm all for making them final. >>> >>> >>> >>> -- >>> This message was sent by Atlassian JIRA >>> (v6.3.4#6332) >> >
