Re: GraphSON3 collections and subtypes

[Robert Dale]

This seems like a special case. If you use valueMap(true), then you do get
back . I still don't understand what this really has to do
with the GraphSON format and less to do with the GLV API.  Shouldn't the
GLV API have a typed return?

Robert Dale

On Fri, Sep 22, 2017 at 6:17 AM, Stephen Mallette 
wrote:

> I can't quite think of how this might work on the server side where the
> serialization takes place. You mentioned that maybe:
>
> > the graph processor could optimize by returning a specific type of
> traverser as a result of the execution of a certain traversal (in the
> example, when the valueMap is the last step).
>
> I think that we've talked about Traversers carrying meta data before.
> Perhaps that's a waynot sure.
>
> On Thu, Sep 21, 2017 at 4:47 AM, Jorge Bay Gondra <
> jorgebaygon...@gmail.com>
> wrote:
>
> > There are 2 ways that I can think of to tackle this from the .NET GLV:
> >  - Provide on demand conversion methods, for example from:
> > Dictionary (default for maps) to Dictionary.
> >  - Do an intermediate parsing, maintaining the original structure that
> gets
> > converted to the provided collection when the user inspects the result.
> > (for example, the original key/value array to Dictionary.
> >
> > There are workarounds, both have some implications...
> >
> > But this is not directly related to C#/.NET. I still think we should try
> to
> > specify the returned data in our serialization format (when thinking of
> > newer versions of GraphSON).
> >
> > On Wed, Sep 20, 2017 at 5:24 PM, Stephen Mallette 
> > wrote:
> >
> > > Is there and alternative on the GLV side? Could the GLV detect
> valueMap()
> > > as the last step and make the conversion appropriately?
> > >
> > > I haven't gone into deep thought on altering GraphSON in the manner you
> > > describe, but without knowing other options it makes me feel uneasy to
> > > think about. hehe
> > >
> > >
> > >
> > > On Wed, Sep 20, 2017 at 4:28 AM, Jorge Bay Gondra <
> > > jorgebaygon...@gmail.com>
> > > wrote:
> > >
> > > > I'm proposing the addition of a new types of map/list/set with
> > specified
> > > > child types. There is no doubt about the need of a map which keys are
> > > > objects (like in groupCount()) and the benefits of using a g:Map over
> > > plain
> > > > json objects in GraphSON3.
> > > >
> > > > > is that basically the core of the usability problem?
> > > >
> > > > I think its a specification problem, not a usability problem.
> > > > GraphTraversal interface exposes valueMap() as a method that returns
> a
> > > > Map, but the GraphSON3 specification doesn't provide an
> > > > specification of a Map with string keys so it's being returned as an
> > > > Map.
> > > >
> > > > > Is there a way to do that? how do we know what's in the Map/List
> > until
> > > we
> > > > iterate it all?
> > > >
> > > > I think its a responsibility of the graph processor, that could
> > optimize
> > > by
> > > > returning a specific type of traverser as a result of the execution
> of
> > a
> > > > certain traversal (in the example, when the valueMap is the last
> step).
> > > >
> > > >
> > > > On Tue, Sep 19, 2017 at 6:56 PM, Stephen Mallette <
> > spmalle...@gmail.com>
> > > > wrote:
> > > >
> > > > > > user is stuck with a unspecified map, which contains strings as
> > keys.
> > > > >
> > > > > so basically in .NET the result of valueMap() is stuck with
> "object"
> > > as a
> > > > > key when the user expects "string". i guess that's inconvenient. if
> > you
> > > > > iterated the keys of the dictionary and wanted to do some string
> > > > operation
> > > > > on that you'd have to cast - is that basically the core of the
> > > usability
> > > > > problem?  i tend to think it's more inconvenient to not be able to
> > get
> > > a
> > > > > proper result from groupCount() where the keys might be something
> > other
> > > > > than a string - we definitely don't want to lose that capability.
> > > > >
> > > > > >  tackle this at the source and try to specify the child types on
> > > > > serialization when we have that information.
> > > > >
> > > > > Is there a way to do that? how do we know what's in the Map/List
> > until
> > > we
> > > > > iterate it all?
> > > > >
> > > > > On Tue, Sep 19, 2017 at 12:38 PM, Jorge Bay Gondra <
> > > > > jorgebaygon...@gmail.com
> > > > > > wrote:
> > > > >
> > > > > > I wanted to bump this open discussion that after the JIRA
> > adjustments
> > > > > > probably got buried.
> > > > > >
> > > > > > On Tue, Sep 12, 2017 at 2:31 PM, Jorge Bay Gondra <
> > > > > > jorgebaygon...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Collections with unspecified child types are useful for mixed
> > > types,
> > > > > but
> > > > > > > we are reusing those types of collections for all the cases.
> > > > > > > This behaviour poses a problem for strict statically typed
> > > languages
> > > > 

Re: GraphSON3 collections and subtypes

[Stephen Mallette]

I can't quite think of how this might work on the server side where the
serialization takes place. You mentioned that maybe:

> the graph processor could optimize by returning a specific type of
traverser as a result of the execution of a certain traversal (in the
example, when the valueMap is the last step).

I think that we've talked about Traversers carrying meta data before.
Perhaps that's a waynot sure.

On Thu, Sep 21, 2017 at 4:47 AM, Jorge Bay Gondra 
wrote:

> There are 2 ways that I can think of to tackle this from the .NET GLV:
>  - Provide on demand conversion methods, for example from:
> Dictionary (default for maps) to Dictionary.
>  - Do an intermediate parsing, maintaining the original structure that gets
> converted to the provided collection when the user inspects the result.
> (for example, the original key/value array to Dictionary.
>
> There are workarounds, both have some implications...
>
> But this is not directly related to C#/.NET. I still think we should try to
> specify the returned data in our serialization format (when thinking of
> newer versions of GraphSON).
>
> On Wed, Sep 20, 2017 at 5:24 PM, Stephen Mallette 
> wrote:
>
> > Is there and alternative on the GLV side? Could the GLV detect valueMap()
> > as the last step and make the conversion appropriately?
> >
> > I haven't gone into deep thought on altering GraphSON in the manner you
> > describe, but without knowing other options it makes me feel uneasy to
> > think about. hehe
> >
> >
> >
> > On Wed, Sep 20, 2017 at 4:28 AM, Jorge Bay Gondra <
> > jorgebaygon...@gmail.com>
> > wrote:
> >
> > > I'm proposing the addition of a new types of map/list/set with
> specified
> > > child types. There is no doubt about the need of a map which keys are
> > > objects (like in groupCount()) and the benefits of using a g:Map over
> > plain
> > > json objects in GraphSON3.
> > >
> > > > is that basically the core of the usability problem?
> > >
> > > I think its a specification problem, not a usability problem.
> > > GraphTraversal interface exposes valueMap() as a method that returns a
> > > Map, but the GraphSON3 specification doesn't provide an
> > > specification of a Map with string keys so it's being returned as an
> > > Map.
> > >
> > > > Is there a way to do that? how do we know what's in the Map/List
> until
> > we
> > > iterate it all?
> > >
> > > I think its a responsibility of the graph processor, that could
> optimize
> > by
> > > returning a specific type of traverser as a result of the execution of
> a
> > > certain traversal (in the example, when the valueMap is the last step).
> > >
> > >
> > > On Tue, Sep 19, 2017 at 6:56 PM, Stephen Mallette <
> spmalle...@gmail.com>
> > > wrote:
> > >
> > > > > user is stuck with a unspecified map, which contains strings as
> keys.
> > > >
> > > > so basically in .NET the result of valueMap() is stuck with "object"
> > as a
> > > > key when the user expects "string". i guess that's inconvenient. if
> you
> > > > iterated the keys of the dictionary and wanted to do some string
> > > operation
> > > > on that you'd have to cast - is that basically the core of the
> > usability
> > > > problem?  i tend to think it's more inconvenient to not be able to
> get
> > a
> > > > proper result from groupCount() where the keys might be something
> other
> > > > than a string - we definitely don't want to lose that capability.
> > > >
> > > > >  tackle this at the source and try to specify the child types on
> > > > serialization when we have that information.
> > > >
> > > > Is there a way to do that? how do we know what's in the Map/List
> until
> > we
> > > > iterate it all?
> > > >
> > > > On Tue, Sep 19, 2017 at 12:38 PM, Jorge Bay Gondra <
> > > > jorgebaygon...@gmail.com
> > > > > wrote:
> > > >
> > > > > I wanted to bump this open discussion that after the JIRA
> adjustments
> > > > > probably got buried.
> > > > >
> > > > > On Tue, Sep 12, 2017 at 2:31 PM, Jorge Bay Gondra <
> > > > > jorgebaygon...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Collections with unspecified child types are useful for mixed
> > types,
> > > > but
> > > > > > we are reusing those types of collections for all the cases.
> > > > > > This behaviour poses a problem for strict statically typed
> > languages
> > > > like
> > > > > > C#. Let's see if I can explain myself with an example:
> > > > > >
> > > > > > valueMap() step yields a map representation. In GraphSON2, it was
> > > > > returned
> > > > > > as a js object (where keys are always strings), that were mapped
> to
> > > C#
> > > > > > Dictionary (equivalent of java's Map > > Object>).
> > > > > > In GraphSON3, it's returned as a "g:Map", that is mapped to C#
> > > > > > Dictionary. As there is no type coercion (ie:
> type
> > > > > erasure
> > > > > > in java) for Dictionary to 

Re: GraphSON3 collections and subtypes

[Jorge Bay Gondra]

There are 2 ways that I can think of to tackle this from the .NET GLV:
 - Provide on demand conversion methods, for example from:
Dictionary (default for maps) to Dictionary.
 - Do an intermediate parsing, maintaining the original structure that gets
converted to the provided collection when the user inspects the result.
(for example, the original key/value array to Dictionary.

There are workarounds, both have some implications...

But this is not directly related to C#/.NET. I still think we should try to
specify the returned data in our serialization format (when thinking of
newer versions of GraphSON).

On Wed, Sep 20, 2017 at 5:24 PM, Stephen Mallette 
wrote:

> Is there and alternative on the GLV side? Could the GLV detect valueMap()
> as the last step and make the conversion appropriately?
>
> I haven't gone into deep thought on altering GraphSON in the manner you
> describe, but without knowing other options it makes me feel uneasy to
> think about. hehe
>
>
>
> On Wed, Sep 20, 2017 at 4:28 AM, Jorge Bay Gondra <
> jorgebaygon...@gmail.com>
> wrote:
>
> > I'm proposing the addition of a new types of map/list/set with specified
> > child types. There is no doubt about the need of a map which keys are
> > objects (like in groupCount()) and the benefits of using a g:Map over
> plain
> > json objects in GraphSON3.
> >
> > > is that basically the core of the usability problem?
> >
> > I think its a specification problem, not a usability problem.
> > GraphTraversal interface exposes valueMap() as a method that returns a
> > Map, but the GraphSON3 specification doesn't provide an
> > specification of a Map with string keys so it's being returned as an
> > Map.
> >
> > > Is there a way to do that? how do we know what's in the Map/List until
> we
> > iterate it all?
> >
> > I think its a responsibility of the graph processor, that could optimize
> by
> > returning a specific type of traverser as a result of the execution of a
> > certain traversal (in the example, when the valueMap is the last step).
> >
> >
> > On Tue, Sep 19, 2017 at 6:56 PM, Stephen Mallette 
> > wrote:
> >
> > > > user is stuck with a unspecified map, which contains strings as keys.
> > >
> > > so basically in .NET the result of valueMap() is stuck with "object"
> as a
> > > key when the user expects "string". i guess that's inconvenient. if you
> > > iterated the keys of the dictionary and wanted to do some string
> > operation
> > > on that you'd have to cast - is that basically the core of the
> usability
> > > problem?  i tend to think it's more inconvenient to not be able to get
> a
> > > proper result from groupCount() where the keys might be something other
> > > than a string - we definitely don't want to lose that capability.
> > >
> > > >  tackle this at the source and try to specify the child types on
> > > serialization when we have that information.
> > >
> > > Is there a way to do that? how do we know what's in the Map/List until
> we
> > > iterate it all?
> > >
> > > On Tue, Sep 19, 2017 at 12:38 PM, Jorge Bay Gondra <
> > > jorgebaygon...@gmail.com
> > > > wrote:
> > >
> > > > I wanted to bump this open discussion that after the JIRA adjustments
> > > > probably got buried.
> > > >
> > > > On Tue, Sep 12, 2017 at 2:31 PM, Jorge Bay Gondra <
> > > > jorgebaygon...@gmail.com>
> > > > wrote:
> > > >
> > > > > Collections with unspecified child types are useful for mixed
> types,
> > > but
> > > > > we are reusing those types of collections for all the cases.
> > > > > This behaviour poses a problem for strict statically typed
> languages
> > > like
> > > > > C#. Let's see if I can explain myself with an example:
> > > > >
> > > > > valueMap() step yields a map representation. In GraphSON2, it was
> > > > returned
> > > > > as a js object (where keys are always strings), that were mapped to
> > C#
> > > > > Dictionary (equivalent of java's Map > Object>).
> > > > > In GraphSON3, it's returned as a "g:Map", that is mapped to C#
> > > > > Dictionary. As there is no type coercion (ie: type
> > > > erasure
> > > > > in java) for Dictionary to Dictionary > object>,
> > > > the
> > > > > user is stuck with a unspecified map, which contains strings as
> keys.
> > > > >
> > > > > This causes a problem in any statically typed languages (outside
> java
> > > > > generics w/ type-erasure thingy).
> > > > >
> > > > > There are workarounds (like exposing conversion methods or lazy
> > > > > deserialization) but maybe we can tackle this at the source and try
> > to
> > > > > specify the child types on serialization when we have that
> > information.
> > > > >
> > > > > On Mon, Sep 11, 2017 at 6:04 PM, Stephen Mallette <
> > > spmalle...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Mixed types would be the problem - that's why objects within the
> > > > List/Map
> > > > 

Re: GraphSON3 collections and subtypes

[Stephen Mallette]

Is there and alternative on the GLV side? Could the GLV detect valueMap()
as the last step and make the conversion appropriately?

I haven't gone into deep thought on altering GraphSON in the manner you
describe, but without knowing other options it makes me feel uneasy to
think about. hehe



On Wed, Sep 20, 2017 at 4:28 AM, Jorge Bay Gondra 
wrote:

> I'm proposing the addition of a new types of map/list/set with specified
> child types. There is no doubt about the need of a map which keys are
> objects (like in groupCount()) and the benefits of using a g:Map over plain
> json objects in GraphSON3.
>
> > is that basically the core of the usability problem?
>
> I think its a specification problem, not a usability problem.
> GraphTraversal interface exposes valueMap() as a method that returns a
> Map, but the GraphSON3 specification doesn't provide an
> specification of a Map with string keys so it's being returned as an
> Map.
>
> > Is there a way to do that? how do we know what's in the Map/List until we
> iterate it all?
>
> I think its a responsibility of the graph processor, that could optimize by
> returning a specific type of traverser as a result of the execution of a
> certain traversal (in the example, when the valueMap is the last step).
>
>
> On Tue, Sep 19, 2017 at 6:56 PM, Stephen Mallette 
> wrote:
>
> > > user is stuck with a unspecified map, which contains strings as keys.
> >
> > so basically in .NET the result of valueMap() is stuck with "object" as a
> > key when the user expects "string". i guess that's inconvenient. if you
> > iterated the keys of the dictionary and wanted to do some string
> operation
> > on that you'd have to cast - is that basically the core of the usability
> > problem?  i tend to think it's more inconvenient to not be able to get a
> > proper result from groupCount() where the keys might be something other
> > than a string - we definitely don't want to lose that capability.
> >
> > >  tackle this at the source and try to specify the child types on
> > serialization when we have that information.
> >
> > Is there a way to do that? how do we know what's in the Map/List until we
> > iterate it all?
> >
> > On Tue, Sep 19, 2017 at 12:38 PM, Jorge Bay Gondra <
> > jorgebaygon...@gmail.com
> > > wrote:
> >
> > > I wanted to bump this open discussion that after the JIRA adjustments
> > > probably got buried.
> > >
> > > On Tue, Sep 12, 2017 at 2:31 PM, Jorge Bay Gondra <
> > > jorgebaygon...@gmail.com>
> > > wrote:
> > >
> > > > Collections with unspecified child types are useful for mixed types,
> > but
> > > > we are reusing those types of collections for all the cases.
> > > > This behaviour poses a problem for strict statically typed languages
> > like
> > > > C#. Let's see if I can explain myself with an example:
> > > >
> > > > valueMap() step yields a map representation. In GraphSON2, it was
> > > returned
> > > > as a js object (where keys are always strings), that were mapped to
> C#
> > > > Dictionary (equivalent of java's Map Object>).
> > > > In GraphSON3, it's returned as a "g:Map", that is mapped to C#
> > > > Dictionary. As there is no type coercion (ie: type
> > > erasure
> > > > in java) for Dictionary to Dictionary object>,
> > > the
> > > > user is stuck with a unspecified map, which contains strings as keys.
> > > >
> > > > This causes a problem in any statically typed languages (outside java
> > > > generics w/ type-erasure thingy).
> > > >
> > > > There are workarounds (like exposing conversion methods or lazy
> > > > deserialization) but maybe we can tackle this at the source and try
> to
> > > > specify the child types on serialization when we have that
> information.
> > > >
> > > > On Mon, Sep 11, 2017 at 6:04 PM, Stephen Mallette <
> > spmalle...@gmail.com>
> > > > wrote:
> > > >
> > > >> Mixed types would be the problem - that's why objects within the
> > > List/Map
> > > >> have types embedded within them.
> > > >>
> > > >> On Mon, Sep 11, 2017 at 12:01 PM, Robert Dale 
> > > wrote:
> > > >>
> > > >> > I'm not sure that's feasible since any list or map could contain
> > mixed
> > > >> > types.  Maybe I don't understand the use case.
> > > >> >
> > > >> > Robert Dale
> > > >> >
> > > >> > On Mon, Sep 11, 2017 at 11:27 AM, Jorge Bay Gondra <
> > > >> > jorgebaygon...@gmail.com
> > > >> > > wrote:
> > > >> >
> > > >> > > Hi,
> > > >> > > The new GraphSON3 g:List, g:Set and g:Map definitions are an
> > > >> improvement
> > > >> > > over js arrays and associative arrays, but they doesn't provide
> > the
> > > >> child
> > > >> > > type information.
> > > >> > >
> > > >> > > We could add support for chid type info, something like
> > > >> > > "g:List" or "g:Map".
> > > >> > >
> > > >> > > For typed languages, it would allow compile time checks.
> > > >> > > For any 

Re: GraphSON3 collections and subtypes

[Jorge Bay Gondra]

I'm proposing the addition of a new types of map/list/set with specified
child types. There is no doubt about the need of a map which keys are
objects (like in groupCount()) and the benefits of using a g:Map over plain
json objects in GraphSON3.

> is that basically the core of the usability problem?

I think its a specification problem, not a usability problem.
GraphTraversal interface exposes valueMap() as a method that returns a
Map, but the GraphSON3 specification doesn't provide an
specification of a Map with string keys so it's being returned as an
Map.

> Is there a way to do that? how do we know what's in the Map/List until we
iterate it all?

I think its a responsibility of the graph processor, that could optimize by
returning a specific type of traverser as a result of the execution of a
certain traversal (in the example, when the valueMap is the last step).


On Tue, Sep 19, 2017 at 6:56 PM, Stephen Mallette 
wrote:

> > user is stuck with a unspecified map, which contains strings as keys.
>
> so basically in .NET the result of valueMap() is stuck with "object" as a
> key when the user expects "string". i guess that's inconvenient. if you
> iterated the keys of the dictionary and wanted to do some string operation
> on that you'd have to cast - is that basically the core of the usability
> problem?  i tend to think it's more inconvenient to not be able to get a
> proper result from groupCount() where the keys might be something other
> than a string - we definitely don't want to lose that capability.
>
> >  tackle this at the source and try to specify the child types on
> serialization when we have that information.
>
> Is there a way to do that? how do we know what's in the Map/List until we
> iterate it all?
>
> On Tue, Sep 19, 2017 at 12:38 PM, Jorge Bay Gondra <
> jorgebaygon...@gmail.com
> > wrote:
>
> > I wanted to bump this open discussion that after the JIRA adjustments
> > probably got buried.
> >
> > On Tue, Sep 12, 2017 at 2:31 PM, Jorge Bay Gondra <
> > jorgebaygon...@gmail.com>
> > wrote:
> >
> > > Collections with unspecified child types are useful for mixed types,
> but
> > > we are reusing those types of collections for all the cases.
> > > This behaviour poses a problem for strict statically typed languages
> like
> > > C#. Let's see if I can explain myself with an example:
> > >
> > > valueMap() step yields a map representation. In GraphSON2, it was
> > returned
> > > as a js object (where keys are always strings), that were mapped to C#
> > > Dictionary (equivalent of java's Map).
> > > In GraphSON3, it's returned as a "g:Map", that is mapped to C#
> > > Dictionary. As there is no type coercion (ie: type
> > erasure
> > > in java) for Dictionary to Dictionary,
> > the
> > > user is stuck with a unspecified map, which contains strings as keys.
> > >
> > > This causes a problem in any statically typed languages (outside java
> > > generics w/ type-erasure thingy).
> > >
> > > There are workarounds (like exposing conversion methods or lazy
> > > deserialization) but maybe we can tackle this at the source and try to
> > > specify the child types on serialization when we have that information.
> > >
> > > On Mon, Sep 11, 2017 at 6:04 PM, Stephen Mallette <
> spmalle...@gmail.com>
> > > wrote:
> > >
> > >> Mixed types would be the problem - that's why objects within the
> > List/Map
> > >> have types embedded within them.
> > >>
> > >> On Mon, Sep 11, 2017 at 12:01 PM, Robert Dale 
> > wrote:
> > >>
> > >> > I'm not sure that's feasible since any list or map could contain
> mixed
> > >> > types.  Maybe I don't understand the use case.
> > >> >
> > >> > Robert Dale
> > >> >
> > >> > On Mon, Sep 11, 2017 at 11:27 AM, Jorge Bay Gondra <
> > >> > jorgebaygon...@gmail.com
> > >> > > wrote:
> > >> >
> > >> > > Hi,
> > >> > > The new GraphSON3 g:List, g:Set and g:Map definitions are an
> > >> improvement
> > >> > > over js arrays and associative arrays, but they doesn't provide
> the
> > >> child
> > >> > > type information.
> > >> > >
> > >> > > We could add support for chid type info, something like
> > >> > > "g:List" or "g:Map".
> > >> > >
> > >> > > For typed languages, it would allow compile time checks.
> > >> > > For any technology, it would more user-friendly error messages
> > >> ("Expected
> > >> > > Vertex, obtained...").
> > >> > >
> > >> > > Jorge
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

Re: GraphSON3 collections and subtypes

[Stephen Mallette]

> user is stuck with a unspecified map, which contains strings as keys.

so basically in .NET the result of valueMap() is stuck with "object" as a
key when the user expects "string". i guess that's inconvenient. if you
iterated the keys of the dictionary and wanted to do some string operation
on that you'd have to cast - is that basically the core of the usability
problem?  i tend to think it's more inconvenient to not be able to get a
proper result from groupCount() where the keys might be something other
than a string - we definitely don't want to lose that capability.

>  tackle this at the source and try to specify the child types on
serialization when we have that information.

Is there a way to do that? how do we know what's in the Map/List until we
iterate it all?

On Tue, Sep 19, 2017 at 12:38 PM, Jorge Bay Gondra  wrote:

> I wanted to bump this open discussion that after the JIRA adjustments
> probably got buried.
>
> On Tue, Sep 12, 2017 at 2:31 PM, Jorge Bay Gondra <
> jorgebaygon...@gmail.com>
> wrote:
>
> > Collections with unspecified child types are useful for mixed types, but
> > we are reusing those types of collections for all the cases.
> > This behaviour poses a problem for strict statically typed languages like
> > C#. Let's see if I can explain myself with an example:
> >
> > valueMap() step yields a map representation. In GraphSON2, it was
> returned
> > as a js object (where keys are always strings), that were mapped to C#
> > Dictionary (equivalent of java's Map).
> > In GraphSON3, it's returned as a "g:Map", that is mapped to C#
> > Dictionary. As there is no type coercion (ie: type
> erasure
> > in java) for Dictionary to Dictionary,
> the
> > user is stuck with a unspecified map, which contains strings as keys.
> >
> > This causes a problem in any statically typed languages (outside java
> > generics w/ type-erasure thingy).
> >
> > There are workarounds (like exposing conversion methods or lazy
> > deserialization) but maybe we can tackle this at the source and try to
> > specify the child types on serialization when we have that information.
> >
> > On Mon, Sep 11, 2017 at 6:04 PM, Stephen Mallette 
> > wrote:
> >
> >> Mixed types would be the problem - that's why objects within the
> List/Map
> >> have types embedded within them.
> >>
> >> On Mon, Sep 11, 2017 at 12:01 PM, Robert Dale 
> wrote:
> >>
> >> > I'm not sure that's feasible since any list or map could contain mixed
> >> > types.  Maybe I don't understand the use case.
> >> >
> >> > Robert Dale
> >> >
> >> > On Mon, Sep 11, 2017 at 11:27 AM, Jorge Bay Gondra <
> >> > jorgebaygon...@gmail.com
> >> > > wrote:
> >> >
> >> > > Hi,
> >> > > The new GraphSON3 g:List, g:Set and g:Map definitions are an
> >> improvement
> >> > > over js arrays and associative arrays, but they doesn't provide the
> >> child
> >> > > type information.
> >> > >
> >> > > We could add support for chid type info, something like
> >> > > "g:List" or "g:Map".
> >> > >
> >> > > For typed languages, it would allow compile time checks.
> >> > > For any technology, it would more user-friendly error messages
> >> ("Expected
> >> > > Vertex, obtained...").
> >> > >
> >> > > Jorge
> >> > >
> >> >
> >>
> >
> >
>

Re: GraphSON3 collections and subtypes

[Jorge Bay Gondra]

I wanted to bump this open discussion that after the JIRA adjustments
probably got buried.

On Tue, Sep 12, 2017 at 2:31 PM, Jorge Bay Gondra 
wrote:

> Collections with unspecified child types are useful for mixed types, but
> we are reusing those types of collections for all the cases.
> This behaviour poses a problem for strict statically typed languages like
> C#. Let's see if I can explain myself with an example:
>
> valueMap() step yields a map representation. In GraphSON2, it was returned
> as a js object (where keys are always strings), that were mapped to C#
> Dictionary (equivalent of java's Map).
> In GraphSON3, it's returned as a "g:Map", that is mapped to C#
> Dictionary. As there is no type coercion (ie: type erasure
> in java) for Dictionary to Dictionary, the
> user is stuck with a unspecified map, which contains strings as keys.
>
> This causes a problem in any statically typed languages (outside java
> generics w/ type-erasure thingy).
>
> There are workarounds (like exposing conversion methods or lazy
> deserialization) but maybe we can tackle this at the source and try to
> specify the child types on serialization when we have that information.
>
> On Mon, Sep 11, 2017 at 6:04 PM, Stephen Mallette 
> wrote:
>
>> Mixed types would be the problem - that's why objects within the List/Map
>> have types embedded within them.
>>
>> On Mon, Sep 11, 2017 at 12:01 PM, Robert Dale  wrote:
>>
>> > I'm not sure that's feasible since any list or map could contain mixed
>> > types.  Maybe I don't understand the use case.
>> >
>> > Robert Dale
>> >
>> > On Mon, Sep 11, 2017 at 11:27 AM, Jorge Bay Gondra <
>> > jorgebaygon...@gmail.com
>> > > wrote:
>> >
>> > > Hi,
>> > > The new GraphSON3 g:List, g:Set and g:Map definitions are an
>> improvement
>> > > over js arrays and associative arrays, but they doesn't provide the
>> child
>> > > type information.
>> > >
>> > > We could add support for chid type info, something like
>> > > "g:List" or "g:Map".
>> > >
>> > > For typed languages, it would allow compile time checks.
>> > > For any technology, it would more user-friendly error messages
>> ("Expected
>> > > Vertex, obtained...").
>> > >
>> > > Jorge
>> > >
>> >
>>
>
>

Re: GraphSON3 collections and subtypes

[Jorge Bay Gondra]

Collections with unspecified child types are useful for mixed types, but we
are reusing those types of collections for all the cases.
This behaviour poses a problem for strict statically typed languages like
C#. Let's see if I can explain myself with an example:

valueMap() step yields a map representation. In GraphSON2, it was returned
as a js object (where keys are always strings), that were mapped to C#
Dictionary (equivalent of java's Map).
In GraphSON3, it's returned as a "g:Map", that is mapped to C#
Dictionary. As there is no type coercion (ie: type erasure
in java) for Dictionary to Dictionary, the
user is stuck with a unspecified map, which contains strings as keys.

This causes a problem in any statically typed languages (outside java
generics w/ type-erasure thingy).

There are workarounds (like exposing conversion methods or lazy
deserialization) but maybe we can tackle this at the source and try to
specify the child types on serialization when we have that information.

On Mon, Sep 11, 2017 at 6:04 PM, Stephen Mallette 
wrote:

> Mixed types would be the problem - that's why objects within the List/Map
> have types embedded within them.
>
> On Mon, Sep 11, 2017 at 12:01 PM, Robert Dale  wrote:
>
> > I'm not sure that's feasible since any list or map could contain mixed
> > types.  Maybe I don't understand the use case.
> >
> > Robert Dale
> >
> > On Mon, Sep 11, 2017 at 11:27 AM, Jorge Bay Gondra <
> > jorgebaygon...@gmail.com
> > > wrote:
> >
> > > Hi,
> > > The new GraphSON3 g:List, g:Set and g:Map definitions are an
> improvement
> > > over js arrays and associative arrays, but they doesn't provide the
> child
> > > type information.
> > >
> > > We could add support for chid type info, something like
> > > "g:List" or "g:Map".
> > >
> > > For typed languages, it would allow compile time checks.
> > > For any technology, it would more user-friendly error messages
> ("Expected
> > > Vertex, obtained...").
> > >
> > > Jorge
> > >
> >
>

Re: GraphSON3 collections and subtypes

[Stephen Mallette]

Mixed types would be the problem - that's why objects within the List/Map
have types embedded within them.

On Mon, Sep 11, 2017 at 12:01 PM, Robert Dale  wrote:

> I'm not sure that's feasible since any list or map could contain mixed
> types.  Maybe I don't understand the use case.
>
> Robert Dale
>
> On Mon, Sep 11, 2017 at 11:27 AM, Jorge Bay Gondra <
> jorgebaygon...@gmail.com
> > wrote:
>
> > Hi,
> > The new GraphSON3 g:List, g:Set and g:Map definitions are an improvement
> > over js arrays and associative arrays, but they doesn't provide the child
> > type information.
> >
> > We could add support for chid type info, something like
> > "g:List" or "g:Map".
> >
> > For typed languages, it would allow compile time checks.
> > For any technology, it would more user-friendly error messages ("Expected
> > Vertex, obtained...").
> >
> > Jorge
> >
>

Re: GraphSON3 collections and subtypes

[Robert Dale]

I'm not sure that's feasible since any list or map could contain mixed
types.  Maybe I don't understand the use case.

Robert Dale

On Mon, Sep 11, 2017 at 11:27 AM, Jorge Bay Gondra  wrote:

> Hi,
> The new GraphSON3 g:List, g:Set and g:Map definitions are an improvement
> over js arrays and associative arrays, but they doesn't provide the child
> type information.
>
> We could add support for chid type info, something like
> "g:List" or "g:Map".
>
> For typed languages, it would allow compile time checks.
> For any technology, it would more user-friendly error messages ("Expected
> Vertex, obtained...").
>
> Jorge
>

GraphSON3 collections and subtypes

[Jorge Bay Gondra]

Hi,
The new GraphSON3 g:List, g:Set and g:Map definitions are an improvement
over js arrays and associative arrays, but they doesn't provide the child
type information.

We could add support for chid type info, something like
"g:List" or "g:Map".

For typed languages, it would allow compile time checks.
For any technology, it would more user-friendly error messages ("Expected
Vertex, obtained...").

Jorge