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 <spmalle...@gmail.com>
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<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 <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<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 <
> > > 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 <robd...@gmail.com>
> > > > 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<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
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
