Its cool, :-)
Cheers
Pieter
On 20/05/2015 17:38, Marko Rodriguez wrote:
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)
