[
https://issues.apache.org/jira/browse/TINKERPOP3-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14560033#comment-14560033
]
Matt Frantz commented on TINKERPOP3-701:
----------------------------------------
(comments from TINKERPOP3-694)
It looks like the various classes that implement {{Mutating}} each contain two
components: (1) the actual mutation logic (e.g. delegation to {{Graph}} or
{{Element}}), and (2) a callback registry. What if the callback API from
{{Mutating}} were given a default implementation, e.g. {{AbstractMutating}}
which delegates to a concrete {{CallbackRegistry}}, so that it could be reused
to build alternatives to the {{Mutating}} classes?
We probably want to promote extensibility via composition from abstract classes
or via delegation to concrete classes, rather than via inheritance of concrete
classes and overriding. The latter is the hardest to maintain for a framework
in the long run, and it would appear that TP2 provided some lessons learned on
that.
If we're not interested in backward compatibility for {{Mutating}}, then
perhaps it should HAS-A {{CallbackRegistry}} instead of IS-A
{{CallbackRegistry}}. This allows combining {{Mutating}} with other interfaces
that might have events.
{code}
interface CallbackRegistry<E extends Event> {
public void addCallback(final EventCallback<E> c);
public void removeCallback(final EventCallback<E> c);
public void clearCallbacks();
public List<EventCallback<E>> getCallbacks();
}
class ListCallbackRegistry<E extends Event> implements CallbackRegistry<E> {
private List<EventCallback<E>> callbacks;
...
}
interface Mutating<E extends Event> {
public CallbackRegistry<E> mutatingCallbackRegistry();
}
interface AbstractMutating<E extends Event> extends Mutating<E> {
private CallbackRegistry<E> callbackRegistry = new
ListCallbackRegistry<E>();
public default CallbackRegistry<E> mutatingCallbackRegistry() { return
callbackRegistry; }
}
{code}
> Improving Mutating Interface
> ----------------------------
>
> Key: TINKERPOP3-701
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-701
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.0.0.GA
> Reporter: Ran Magen
> Priority: Critical
>
> This was discussed in the mailing list. Ill quote the relevant parts:
> We want to implement a validation strategy. Sort of like EventStrategy, but
> it will notify before a mutation, and will enable the user's validation code
> to cancel a mutation if it doesn't pass its checks. The problem is that there
> are no "before" callbacks for the Mutating interface.
> Stephen Mallette:
> i may have messed up the Mutating interface design a bit. looking at it now,
> i feel like it could be less coupled to the EventStrategy related features.
> I'll take a look at it to see if I can make it "better" before GA. I don't
> think my changes should affect vendors or the test suites, so if it turns out
> to be that way i'll give it a shot.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
