Hi everyone,
I wanted to share some thoughts on the current state of the Configuring and
Parameterizing interfaces. As it stands, these 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.
My understanding is that Parameterizing was initially introduced as a mechanism
to support folding properties into addV/addE steps,
and was later co-opted as a convenient structure to use for with()-modulation.
The dual purpose of these interfaces leads to strange
behaviours such as the ability to set properties via with modulators:
gremlin> g.addV().with("name", "cole").valueMap()
==>[name:[cole]]
As part of the ongoing work in 3.8-dev, 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.
My proposal is to isolate any state not related to with()-modulation from
Configuring/Parameterizing interfaces. My criteria for this are
that TinkerPop will never call the configure() method on a step except in
response to a with() modulator, and that the Parameters returned
by getParameters() will only contain configurations originating from with()
modulators. I imagine classes such as AddVertexStep may still
leverage a second private Parameters objects to store its internal state,
however going forward this will not be publicly exposed at all.
Any accesses and mutations of these steps will be forced to use the new
contract interfaces instead.
Please let me know if you have any thoughts or concerns regarding this
proposal. If there are no objections, I plan to put together a PR
with this change in the coming days.
Thanks,
Cole
