[
https://issues.apache.org/jira/browse/TINKERPOP-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031063#comment-16031063
]
Florian Hockmann commented on TINKERPOP-1552:
---------------------------------------------
It's good that you bring up the issue of naming the GLV and the driver because
I am also not sure if the current naming makes sense as it is. But let me
explain my reasoning so that we can discuss about it:
# Gremlin-DotNet is an extended version of the current [Gremlin.Net
project|https://github.com/FlorianHockmann/Gremlin.Net]. So it would be ideal
if we could keep the name {{Gremlin.Net}} for the NuGet package. That way
existing users can simply update the package and then start using the GLV
anytime they want as it still also works the old way with Gremlin query
strings. (By the way: It would be a good idea in my opinion to list
{{Gremlin.Net}} on the TinkerPop page so that new users start with that driver
instead of the abandoned Teva Gremlin.)
# The driver is independent of the actual programming language being used.
Currently we only think about the C# GLV, but there could also be other .NET
GLVs like Gremlin-FSharp or Gremlin-PowerShell. All .NET GLVs should be able to
use this driver. That is why I would like to not include C# in its name and
instead use something that just stands for .NET in general.
# I tried to stick to the TinkrePop naming convention for the module names
which is Gremlin-Python, Gremlin-Java, and so on. Hence the modules are named
Gremlin-DotNet (Gremlin-Net would be another option) and Gremlin-CSharp.
# Since [the .NET naming convention states that hyphens and underscores should
not be used|https://msdn.microsoft.com/en-us/library/ms229045(v=vs.110).aspx],
the C# projects use the _dotted_ versions: {{Gremlin.CSharp}}, {{Gremlin.Net}},
and {{Gremlin.Ne.Processt}}.
# The last issue is not really a naming issue, but more an issue about the
general organization into projects. I already gave a short description of the
three projects in the pull request:
{quote}
{{Gremlin.CSharp}} is the C# GLV, it is nearly completely auto generated
(except for the Graph class)
{{Gremlin.Net}}: Contains the driver that is basically an extension of the
existing Gremlin.Net driver and the structure API, including GraphSON writers
and readers.
{{Gremlin.Net.Process}}: Driver independent implementation + interfaces of
common functionality for .NET GLVs. Allows Gremlin-CSharp to be used together
with another driver.
{quote}
So this structure allows to add new GLVs that can reuse the driver and common
implementations and interfaces from {{Gremlin.Net}} and
{{Gremlin.Net.Process}}. Additionally, users can user the GLVs with other
drivers, because all interfaces necessary for that are contained in
{{Gremlin.Net.Process}}. This allows to leave out {{Gremlin.Net}} and use some
other driver instead.
Having one project named {{Gremlin.Net}} and another {{Gremlin.Net.Process}}
might be a bit confusing as it looks as if {{Gremlin.Net.Process}} should be a
part of {{Gremlin.Net}}. So it might be a good idea to split up {{Gremlin.Net}}
into {{Gremlin.Net.Driver}} and {{Gremlin.Net.Structure}} (in addition to the
existing {{Gremlin.Net.Process}}.
Regarding the casing of the generated enums: I first tried to also use pascal
case for enum values, but the problem is that they have to be converted back to
the original TinkerPop enum values when they are used in Gremlin Bytecode.
Unfortunately [not all enum values are pascal case in
TinkerPop|https://github.com/apache/tinkerpop/blob/bdb21f2d0a0bcaac62c392bc779aae635673313d/gremlin-dotnet/src/Gremlin.CSharp/Process/Direction.cs]
which makes this conversion non-trivial. That is why I just used the original
enum values instead.
> 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)
