[jira] [Closed] (TINKERPOP-1523) A means of clarifying an explicit type in DSL with language variants
[ 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)
[jira] [Closed] (TINKERPOP-1523) A means of clarifying an explicit type in DSL with language variants
[ 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 I think Marko's comment makes sense: we'll include {{asFloat()}} type methods as needed in a GLV to support it. As there hasn't been any additional update to this issue in recent time I'm going to close it out. Please reopen as necessary. > 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: language-variant >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)