[
https://issues.apache.org/jira/browse/TINKERPOP-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1523.
---------------------------------------
Resolution: Won't Do
> 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: Improvement
> Components: io, process
> Affects Versions: 3.2.3
> 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.4.14#64029)
