Andy Tolbert created TINKERPOP-1523:
---------------------------------------
Summary: A means of clarifying an explicit type in DSL with
language variants
Key: TINKERPOP-1523
URL: https://issues.apache.org/jira/browse/TINKERPOP-1523
Project: TinkerPop
Issue Type: Wish
Components: language-variant
Reporter: Andy Tolbert
Priority: Minor
Depending on the host programming language, it is not possible/clear when
implementing a gremlin language variant how a user could communicate a given
type that is not supported in their language.
For example, in python and javascript, there isn't a way to differentiate
between a float and a double, yet {{Double}} and {{Float}} are valid types in
gremlin language variants.
In the case of deserializing, it is pretty clear what needs to be done, the
code needs to coerce the types into a type that host language can handle, as
specified in the [GLV
docs|https://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/]:
{quote}
Language drivers are responsible for submitting Gremlin traversals to a
TinkerPop-enabled graph system and returning results to the developer that are
within the developer’s language’s type system. For instance, resultant doubles
should be coerced to floats in Python.
{quote}
What isn't clear to me is what to do in the serialization case. As the type is
optional, you could simply provide the numerical value and leave it to the
backend implementation to handle it appropriately, but the type can cause the
backend to handle things differently. For example, if the backend generates a
schema on the fly, it might decide that a value of 2 is an {{Int32}} when maybe
what the user wanted was a {{Int16}} for example. You could argue that you
could predefine the schema to avoid this, but lets ignore that for a moment.
I think it would be nice is if there was some way in the DSL for the user to
communicate the underlying type that should be used in the traversal, i.e.:
{code:javascript}
g.E().has("weight", asFloat(0.2))
{code}
{{asFloat}} and other {{asXXX}} methods could be a way for a host environment
without an adequate type system to communicate the underlying type. Also, a
{{as(typename)}} method could be useful for communicating arbitrary types that
are maybe implementation specific.
Any implementation could provide this functionality themselves, but I'm
wondering if it would be useful to make this part of the specification of
things a GLV implementation could provide, that way there is a somewhat
standard way of communicating types in absence of types in the host language.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
