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 way....not sure. On Thu, Sep 21, 2017 at 4:47 AM, Jorge Bay Gondra <[email protected]> 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<object, object> (default for maps) to Dictionary<K, V>. > - 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<K, V>. > > 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 <[email protected]> > 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 < > > [email protected]> > > 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<String, E2>, but the GraphSON3 specification doesn't provide an > > > specification of a Map with string keys so it's being returned as an > > > Map<Object, Object>. > > > > > > > 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 < > [email protected]> > > > 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 < > > > > [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 > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >
