[ 
https://issues.apache.org/jira/browse/TINKERPOP-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18021959#comment-18021959
 ] 

ASF GitHub Bot commented on TINKERPOP-3193:
-------------------------------------------

Cole-Greer opened a new pull request, #3215:
URL: https://github.com/apache/tinkerpop/pull/3215

   https://issues.apache.org/jira/browse/TINKERPOP-3193
   
   Updates AddVertexStep, AddVertexStartStep, AddEdgeStep, AddEdgeStartStep, 
and AddPropertyStep
   to isolate internal state management (used for id, label, properties, 
from/to...) from the
   Paramenters object used by Configuring and Parameters interfaces. These 
interfaces are now
   exclusively used for the purposes of with() modulation. All other existing 
usages of Parameters
   in Configuring steps is exclusively related to with() modulation.
   
    VOTE +1




> 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
>            Priority: Major
>
> 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