Naming conventions in GOOL for Java vs Julia

[B-rando1]

I noticed that in a few places in GOOL (see below for example), data types for the Java backend are prefixed with a single J or j. Since we'll be adding Julia, this seems like it could be a confusing naming scheme.

https://github.com/JacquesCarette/Drasil/blob/e974d5af2f0f4e2433b5066aeed4d17499766557/code/drasil-gool/lib/GOOL/Drasil/LanguageRenderer/JavaRenderer.hs#L115-L118

For now I'll prefix code referring to Julia with Jl or jl to match its file extension, but there might be a larger discussion to be had here on descriptive names, or at least for Java in particular. What are your thoughts?

[balacij]

The Julia renderer would be in a separate file, so don't worry too much about naming private/local data. The exports of the prospective JuliaRenderer would probably only contain the JuliaCode type and the special features unique to Julia (I'm not sure of what features there are). Prefixing those unique Julia features with something like jl sounds good. It's their file extension, too.

[smiths]

The question has been answered, so I think we can close this issue. @B-rando1 please reopen if I am incorrect on my assumption.

[B-rando1]

Actually there are some places where those structures are sharing a namespace. For example, the main GOOL.Drasil module imports them all into the namespace:

https://github.com/JacquesCarette/Drasil/blob/e974d5af2f0f4e2433b5066aeed4d17499766557/code/drasil-gool/lib/GOOL/Drasil.hs#L63-L67

And in drasil-code/test, some of those types are passed as parameters to the generator:

https://github.com/JacquesCarette/Drasil/blob/e974d5af2f0f4e2433b5066aeed4d17499766557/code/drasil-code/test/Main.hs#L25-L31

[B-rando1]

I was talking with @balacij, and I just thought I should clarify what my point is.

For background, there are a few places, such as that second example from my previous comment, where the code is referring to the generator instances for each of the target languages in turn, meaning that there's code mentioning unJP for Java, unPP for Python, unCSP for C#, unCPPP for C++, and unSP for swift, all in the same area.

So far the names of the target languages have been different enough that that's been fine, there's no way you'd confuse unJP with unCSP for example. But now we're adding Julia, and it would be a lot easier for someone to confuse unJP for Java with unJLP for Julia. So my question was, should we change the postfixes of these (and similar functions) to follow a clearer naming scheme, for example based on file extension?

As @balacij discussed over Discord, this should be easy to change at any time so it's not a priority; I just thought I should bring it up.

[JacquesCarette]

If our names are too short and causing conflicts, we can lengthen them. We can also move to using more qualified names, which is probably a better way to deal with it.

This is a small thorn, but they eventually hurt, so it's worthwhile making the small improvements.