> 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 <[email protected] > 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 < > [email protected]> > 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<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 > >> > > > >> > > >> > > > > >
