or you know, use an IDE!
Named Parameters in Java
11–20 of 62 posts
Re: Named Parameters in Java
#12Whoever wrote the original code is missing a major point in OOP: you should (almost) never be passing in simple types. Create an object that holds the data (class IDObject, for instance), and pass an instance of this class in for the parameter. Then, the parameters are de facto named in the data object. This importance of this method is that it allows the you to update the information passed in via the data object (w…
OTOH, I kind of like languages that support map literals and/or tuples, rather than making me define a new class for use in a single place as a parameter object or return value.
On the gripping hand: click on the method name (in an IDE), and let the IDE tell you what the params are to the method. Why bother with static typing if you aren't going to use the information?
Re: Named Parameters in Java
#13I would not use a separate class per parameter though that is a clever solution. It might hurt performance and it just feels a bit heavy.
For performance, clarity and reusability I would simply create a class that holds the values needed. Add an @Entity tag and now it can be used as a Hibernate persistence class too.
Re: Named Parameters in Java
#14It might be crazy but I like this kind of DSLization of Java a lot
It doesn't seem all that crazy to me. I wouldn't be surprised to see an ML programmer write something like
datatype name = Name of string
Re: Named Parameters in Java
#15Whoever wrote the original code is missing a major point in OOP: you should (almost) never be passing in simple types. Create an object that holds the data (class IDObject, for instance), and pass an instance of this class in for the parameter. Then, the parameters are de facto named in the data object. This importance of this method is that it allows the you to update the information passed in via the data object (w…
Never passing in simple types? I don't know about you, but one of the reasons I like languages such as Python and JavaScript is I don't have to create a wrapper object for every type I'm using. The fact I had to, for instance, create URL and IP Address and such objects in C# drove me crazy.
When I program in Python I would do it the same way, create a class that represents the types. The class can be made into a persistence class easily, this approach is clear, readable and maintainable. Oh and I try to avoid JavaScript, too much clever coding makes it a hard language to maintain.
Re: Named Parameters in Java
#16or you know, use an IDE!
This is a good observation, people who seem to like named parameters strike me as people who might code in plain text editors a lot. Nothing wrong with that but an IDE makes things so much easier and faster.
Re: Named Parameters in Java
#17Whoever wrote the original code is missing a major point in OOP: you should (almost) never be passing in simple types. Create an object that holds the data (class IDObject, for instance), and pass an instance of this class in for the parameter. Then, the parameters are de facto named in the data object. This importance of this method is that it allows the you to update the information passed in via the data object (w…
On the other hand, the Law of Demeter says that you should almost always be passing in and fetching primitive types. At least in an API. Does it not?
Though I'm guessing that "primitive types" would include algebraic data types, which serve the same purpose here as little objects like IDObject. And since Java doesn't have algebraic data types.... All the more reason to switch to Scala.
Edit: I should have written "built-in types" above, rather than "primitive types".
Re: Named Parameters in Java
#18Wow this would make for some crazy code to try to read thru. I would be über-pissed to trace thru code like this only to find all of these wrapper classes. This is what Javadocs are for, it's much easier and cleaner just to document your code as you write it.
This. I'd do my best to make sure the authors contributions stopped. Type safety obviously doesn't protect you the worst possibilities in software.
Re: Named Parameters in Java
#19Although the solution produces too many problems, I agree that named parameters are highly desirable for readability and the prevention of bugs. Have there been any proposals for Java 8 to included named parameters?
Edit:
* http://openjdk.java.net/jeps/118 proposes run-time storing of parameter names -- not what is desired, but in the same ballpark.
* http://web.archiveorange.com/archive/v/bobySzLnuDWgr47zqwU9 proposes named arguments for making clean code.
Re: Named Parameters in Java
#20Earlier quoted context omitted.
I think it would really shine with IDE support. It probably wouldn't even be that hard to do (famous last words). I think I'll take a stab at it. I like it as well, and have done similar things by creating input/output classes to use as "structs" when the list of parameters gets unweildy or when I want multiple returns.
When "the list of parameters gets unweildy" and "I want multiple returns" are to major indicators that you got some anti-patterns going on. I think the refactoring that you need might a new class with a single responsibility.
Or they are indicators that you have experience in languages that allow such designs, and would like java to introduce them. My biggest problem with java is that it tried to be a single paradigm langues: object oriented. While it was doing that, people worked on developing other methods. Concepts from these other systems are beggining to creep into java. For example, generics are a functional concept, as are lambdas which will be introduced in the next version.