[jira] [Created] (TINKERPOP-1523) A means of clarifying an explicit type in DSL with language variants

["Andy Tolbert (JIRA)" <ji...@apache.org>]

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)