Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/842
> @FlorianHockmann Why would we do that? If we can construct (i.e.
deserialize) e.g. a DateTime of whatever a server gives us, fine. Doesn't mean
we have to send (i.e. serialize) obscure types. As it currently is, it's more
of an 'it just works'-approach.
I think the problem Jorge sees with that is the following:
1. You receive e.g. an `gx:Instant`.
2. It gets deserialized to `DateTime`.
3. You work with this `DateTime` and then send it back to the server.
4. It will be serialized to `g:Date`. <- Can't be used where the original
`gx:Instant` came from.
but right, lets wait for him to come back on this.
> I think the point is to establish the intent to users that we no longer
intend to support a type at some point in the future. I'm not sure what
deprecation means in the IO sense.
Ok, since I'm also not sure about how we would want to handle the
"deprecation" of types but since we seem to agree on the fact that
communicating to users somehow which types they can expect to be supported
across GLVs and which ones not, I'll start a DISCUSS thread on the mailing
list. Maybe others have good ideas for that.
---
