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
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
