What is the use of adding type information to e.g ElementMap<type> in Gremlin.Net?
Consider the query and output in the attached image: What TYPE could be placed inside the
ElemementMap<TYPE> that has any real value?
The return type of ElementMap<TYPE> is a dictionary, and setting e.g ElementMap<IDictionary<string,string>>() would return make dotnet try to fit all vertex properties against a IDictionary<string,string> type - which only would work if all property values of the vertex are of type string.
To frame it differently: is there any scenario in which I do not want to write ElemementMap<object> or ElemementMap<dynamic>?
7 Replies
Usually property values are mixed as you say, so the typical return for typed languages is
object. It's worth noting that <string,string> doesn't really even work too well since T and Direction enum values can be returned as keys.This is my observation as well. Would it perhaps be just as well to remove the type all together? Default it to
object? I find the IDictionary-like types quite distracting in Gremlin.Net (and difficult for beginners), so I would argue a case of removing them until a better solution (like an ORM) is implemented.@Florian Hockmann do you have opinion on this? ☝️ I'm not expert at .NET but I'll just say that the project strives to make Gremlin feel at home in every programming language, which means following its idioms and expected usage patterns.
To be honest, I don't have a strong preference regarding type information for steps that only return a Dictionary. The reason these steps are implemented like this is only because we originally generated them from the Java steps and tried to stay as close as possible to them. The type information is helpful for some steps where they limit the number of steps that are possible afterwards and the type information is also forwarded to the returned types so you now what type you are getting back from a traversal, but yeah, for something like
ElementMap(), we could probably just use a default type like object instead of letting users specify that explicitly.
And if we see a benefit in being able to specify that a Dictionary should only be Dictionary<string,string> or Dictionary<string, int> or so instead of Dictionary<object, object>, then we could maybe use overloads: One with generic type parameters and one without that just uses object
Do you want to create an issue for this? https://issues.apache.org/jira/projects/TINKERPOP/issues
If you want to, then you can of course also directly create a PR for this. If it's breaking (so replacing the existing steps), then that should target master and it will then be released in 3.7.0, if it's non breaking then you can target 3.5-dev so it can land in all following releases@Florian Hockmann I'm with you on the reasoning. We are a team of developers working with the Gremlin.Net APis at the moment. If we find good solutions for these kinds of things we'll try to add them here/as issues/as PRs to improve overall experience.
I must say, you are doing amazing work! We wouldn't have decided on trying Gremlin.Net if it were not for your quick responses and works of many others I see here on Discord. 🙂
glad to hear you are enjoying discord. please keep the questions and suggestions coming 
Thanks for your feedback. That's definitely great to hear 😃
Looking forward to any issues & especially PRs of course 😉