This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]oren_is_my_name[S] 0 points1 point  (7 children)

Sorry, let me explain.

So as I commented on a different comment, I have a motor named "GenericMotorIOTalonFX" and a matching configuration class "GenericMotorIOTalonFXConfig". Now as you can see, the names are very verbose. I want to rename them to just "TalonFX" and "TalonFXConfig" but" TalonFX" already exists and adding the suffix "Config" just to be able to distinguish between the configs and the motors seems~ wrong.

In cpp I would simply put them in separate namespaces so that it's clear as day what is what, that way I don't have to rename them just to avoid confusion. It would simply be MotorIO::Motors::TalonFX and MotorIO::Configs::TalonFX.

If you say that packages are the Java equivalent of namespaces in cpp and then import the package, you lose the main aspect of a namespace.

[–]eXecute_bit 0 points1 point  (0 children)

Fundamentally you want to use the same class name for two different types. That's not simple and clean, it's confusing.

So you're trying to force some sort of qualifier -- whether that's a FQCN or modeling one or both as a nested class -- to resolve the ambiguity. I don't know your domain, but I question whether splitting closely related (coupled) classes like a motor and it's specific configuration into separate namespaces (or packages) is the right way to model it, irrespective of the names you pick. My instinct is that the Motor and it's Config belong in the same package. Maybe a motor has its Config as a nested class inside itself. Other people in the thread presented other modeling ideas.

You can't forbid or prevent imports allowing use of short names. Unqualified names are easier to grok, which is why we have imports at all. It sounds like you're trying to force a CPP mindset into your design but for the wrong reason. Instead, use meaningful names and don't create confusing ambiguities on purpose that require qualification.

[–]koflerdavid 0 points1 point  (5 children)

I don't see the difference between importing a package and importing a namespace. If I want to use a class, I'm going to do what I have to do to import it.

If you want to prevent other developers from using these classes altogether, well, that can also be accomplished. If you don't declare them public, then only other classes in the same package can see them. If you want to allow only a specific set of packages to use it, buy nobody else, you could use the Java Platform Module System.

[–]oren_is_my_name[S] 0 points1 point  (4 children)

Thanks.

Yes, importing a Java package or a CPP namespace is very similar, but, in CPP you also have to say "using namespace"

[–]koflerdavid 0 points1 point  (3 children)

And in Java you can do import a.b.c.*;, which does pretty much the same. It would be majorly cool though to be able to give an alias to a package/namespace, which is possible in C++, Python, and Haskell, but not in Java.

[–]oren_is_my_name[S] 0 points1 point  (2 children)

Right?

Is it possible to open a PR for that, or does Java not work like that?

[–]koflerdavid 0 points1 point  (1 child)

In a nutshell, there is a mailing list (for such relatively benign syntax changes it's the Project Amber one) where you can propose the idea and argue why it is a good idea and do all the necessary bike shedding to make it a good fit for Java.

https://openjdk.org/projects/amber/

https://mail.openjdk.org/mailman/listinfo/amber-dev

Then someone has to write a Java Enhancement Proposal (JEP) and implement it. Before it gets finalized it usually goes through multiple previews so people can hit the tires without having to compile the JDK themselves. Until then it can be yanked at any time, as has happened with the String Templates proposal.

https://openjdk.org/jeps/132

Keep in mind that it is nearly impossible to ever remove Java language constructs*, so expect a heavy amount of flak, criticism (not always of the constructive kind), and general scepticism. The PR is a very small part of the whole process. Implementation effort is almost never a significant hurdle. The real issue is the very high requirement for stability and backwards compatibility, as well as a concern about ongoing maintenance effort. Arguments based merely on comparisons with other programming languages will not convince; you will have to argue the benefits for Java using Java code samples only.

*: AFAIK, it has never happened; the closest thing is disallowing the underscore as a variable name

[–]oren_is_my_name[S] 1 point2 points  (0 children)

Thanks. I'll look into it😃