[
https://issues.apache.org/jira/browse/TINKERPOP-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15465128#comment-15465128
]
Robert Dale commented on TINKERPOP-1427:
----------------------------------------
Technically, that's not correct. 2 == 2L. I think you mean Integer(2) !=
Long(2). But we all know you should never use operators on objects, so what
you really means is !Integer(2).equals(Long(2)). However, numbers should never
be compared using equals() at least not without being promoted to like types.
The JVM automatically promotes primitives to like types but unfortunately not
for objects. This is left as an exercise to the user. If numbers are not
converted to primitives or promoted to like types, then your comparison is
fundamentally broken.
It seems that the only underlying graph that's holding this back is TinkerGraph
where Modern and TheCrew don't implement proper IdManagers for whatever reason.
Are there any real-world implementations that don't sanely promote and compare
numbers? I'm not aware of any.
Consider the user perspective, what makes sense? What user expects 2 != 2?
What other languages exhibit this behavior? Is there any precedent at all that
supports this behavior outside of this java idiosyncrasy?
Maybe storage size should be extended to strings. There should be a String32
and String64. That way it would be consistent with numbers such that "gremlin"
!= "gremlin". Yes, I'm being facetious but trying to make a point on how
ludicrous this is.
All that aside, assuming that gremlin does not strive to be language-agnostic
and continue shove java idiosyncrasies down everyone's throat, the question
still stands on how will this actually be supported on weakly-typed clients?
Will you create new types TinkerInt, TinkerLong, etc? g.V(TinkerInt(2))? Or
will the driver need to reference a schema to build the correct types? or is
there some other option?
> GraphSON 2.0 needs collection types and consistent number typing.
> -----------------------------------------------------------------
>
> Key: TINKERPOP-1427
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1427
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
> Affects Versions: 3.2.1
> Reporter: Marko A. Rodriguez
> Labels: breaking
>
> Before 3.3.0, we need to get the story around collections straight. Currently
> we are relying on JSON collections to represent our collections, but this
> isn't always sound -- e.g. JSON maps can only have string keys.
> Thus, we need:
> {code}
> g:Map
> g:List
> g:Set
> {code}
> Note that all of these would just be JSON lists:
> {code}
> {@type:"g:Map", @value:[key1,value1,key2,value2,key3,value3,...]}
> {@type:"g:List", @value:[value1, value2, value3,...]}
> {@type:"g:Set", @value:[value1, value2, value3,...]}
> {code}
> ---
> Next, these data structures are exactly what play into {{aggregateTo}} in
> sideEffects for {{RemoteConnection}}. Thus, we should use these types and, as
> well, get rid of {{none}} as the aggregate would be a real type like
> {{g:Int32}}.
> Also, I think we should abandon this hybrid physical machine naming
> convention and programming language type convention.
> {code}
> g:Int32 -> g:Integer
> g:Int64 -> g:Long
> g:Double -> g:Double (no change)
> g:Float -> g:Float (no change)
> {code}
> If we want to be consistent either do the above or do the below, though I
> think the above is cleaner.
> {code}
> g:Int32 -> g:Int32
> g:Int64 -> g:Int64
> g:Float -> g:Float32
> g:Double -> g:Float64
> {code}
> Again, using programming lexicon vs. physical machine lexicon is best and
> thus, just gut "int32" and "int64."
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
