[
https://issues.apache.org/jira/browse/TINKERPOP-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16029283#comment-16029283
]
Florian Hockmann commented on TINKERPOP-1552:
---------------------------------------------
Thanks for your feedback [~jorgebg]!
I already talked about my motivation for the first two points you make above:
1) Naming convention (camel case for all GLVs vs language specific conventions)
{quote}
One design decision I took: The method names comply with .NET conventions and
therefore use pascal case, so `g.V().has('name','marko').next()` becomes
`g.V().Has('name','marko').Next()`. This should make it feel very natural for
any C# programmer to work with Gremlin-CSharp. An added benefit is that it
avoids reversed keywords in C# like `in` or `as` that would require a special
treatment otherwise.
{quote}
So my reasoning behind this was basically that a typical project will only
include one GLV. That is why I think that consistency within the language is
more important than consistency across all Gremlin GLVs. When the GLVs are
_fully developed_ a user should not have to switch between different GLVs. So
the only place where he will encounter a different GLV is the documentation,
but we could also solve this in the long term by adding a kind of language
switch to the documentation so that every user can read the documentation for
his own programming language. Having pascal case mixed in a .NET project that
uses pascal case on the other hand looks unnatural and it would require a
special treatment for reserved keywords which adds unnecessary confusion that
we can avoid when we stick to the language specific convention.
But I agree that we should discuss this and it won't be difficult to change
Gremlin-CSharp to use camel case instead if that is what we agree on.
2) Generics
{quote}
In general, Gremlin-CSharp is very close to Gremlin-Python. This also means
that it is not type-safe, all steps simply expect a `params object[]`. It was
very easy to generate Gremlin-CSharp this way but this should be improved in
the future.
{quote}
Using generics is of course the way to go in the long term but it requires more
effort to generate Gremlin-CSharp with generics and I just wanted to create a
first version of it quickly. I actually gave it a short try with a mapping of
Java types to .NET types but I chose to focus first on Gremlin-DotNet with the
driver. So I completely agree with you here. I simply didn't have the time yet
to implement this.
Maybe we should focus this issue on the first basic version of Gremlin-CSharp
and Gremln-DotNet and create new issues for features like this that can be
added afterwards?
3) Since the traversal is responsible for the iterating itself, implementing
{{IEnumerator}} felt more natural to me than implementing {{IEnumerable}}.
{{IEnumerator}} contains the methods {{Current}}, {{MoveNext}} and {{Reset}}
which are really close to what a traversal is in TinkerPop. But if you have a
good way to let the traversal implement {{IEnumerable}} that still fits
together with TinkerPop's methods like {{Next}} then I would definitely support
that contribution!
> C# Gremlin Language Variant
> ---------------------------
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
> Issue Type: Improvement
> Components: language-variant
> Affects Versions: 3.2.3
> Reporter: Jorge Bay
> Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of
> the trickier bits to deal with.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
