Andy Tolbert created TINKERPOP-1523:

             Summary: A means of clarifying an explicit type in DSL with 
language variants
                 Key: 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 

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.

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.:

g.E().has("weight", asFloat(0.2))

{{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

Reply via email to