Cole Greer created TINKERPOP-3193:
-------------------------------------

             Summary: Decouple non with()-related configs from 
Configuring/Parameterizing interfaces
                 Key: TINKERPOP-3193
                 URL: https://issues.apache.org/jira/browse/TINKERPOP-3193
             Project: TinkerPop
          Issue Type: Improvement
          Components: process
    Affects Versions: 3.7.4
            Reporter: Cole Greer


Currently, the Configuring and Parameterizing interfaces serve two distinct 
purposes. The most notable purpose is that these interfaces enable 
with()-modulation for a step. Additionally, there are a handful of steps such 
as AddVertexStep, AddEdgeStep, and AddPropertyStep which utilize Parameters to 
store their internal state. The dual purpose of these interfaces leads to 
strange behaviours such as the ability to set properties via with modulators:


{code:java}
gremlin> g.addV().with("name", "cole").valueMap()
==>[name:[cole]]
{code}


As part of the ongoing work leading to 3.8.0, we’ve extracted StepContracts 
(interfaces) from many steps including the ones listed above.
These contracts expose new methods to interact with a step’s contents in a 
controlled manner instead of by directly accessing the
Parameters (getElementId(), getLabel(), addProperty()…). The presence of these 
new interfaces creates an opportunity to escape the
internal-state management role of Parameterizing, and change 
Configuring/Parameterizing to be purely focused on with()-modulation.

We should isolate any state not related to with()-modulation from 
Configuring/Parameterizing interfaces. TinkerPop should never call the 
configure() method on a step except in response to a with() modulator, and that 
the Parameters returned by getParameters() should only contain configurations 
originating from with() modulators. Classes such as AddVertexStep may still 
leverage a second private Parameters objects to store its internal state, 
however this should not be publicly exposed at all. Any accesses and mutations 
of these steps should be forced to use the new contract interfaces instead.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to