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<string, object> (equivalent of java's Map<String, Object>).
In GraphSON3, it's returned as a "g:Map", that is mapped to C#
Dictionary<object, object>. As there is no type coercion (ie: type erasure
in java) for Dictionary<string, object> to Dictionary<object, 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 <[email protected]>
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 <[email protected]> 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 <
> > [email protected]
> > > 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<g:Traverser>" or "g:Map<g:Int32,g:Vertex>".
> > >
> > > For typed languages, it would allow compile time checks.
> > > For any technology, it would more user-friendly error messages
> ("Expected
> > > Vertex, obtained...").
> > >
> > > Jorge
> > >
> >
>

Reply via email to