[jira] [Commented] (TINKERPOP-3193) Decouple non with()-related configs from Configuring/Parameterizing interfaces

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

    [ 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)