Named Parameters in Java • Hacker News Board

Re: Named Parameters in Java

#21

Post by nessus42 » Fri, Aug 10, 2012, 2:13 PM UTC

TazeTSchnitzel wrote: post #10

dhimes wrote: post #6

Whoever 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.

Named tuples are nice in Python.

I wonder how easy it is, though, to modify a namedtuple constructor to do argument validation and to allow for default field values.

Re: Named Parameters in Java

#22

Post by peeters » Fri, Aug 10, 2012, 2:14 PM UTC

nessus42 wrote: post #17

dhimes wrote: post #6

Whoever 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 "b…

Hmm, I've never seen Demeter interpreted to mean that you should favour primitives over rich types. Can you explain your interpretation?

Re: Named Parameters in Java

#23

Post by SeanLuke » Fri, Aug 10, 2012, 2:16 PM UTC

josemando wrote: post #4

Coming back to Java after learning Objective-C made realize how named parameters are awesome

Objective-C doesn't have named parameters (that is, Lisp-like "keyword" parameters). It has a hack which allows a method to be so named that it has to be used in a named way. Named parameters can be in any order and may or may not exist in the function call. Obj-C can't do this because its "names" are actually just part of the method signature. It's fake.

Re: Named Parameters in Java

#24

Post by arethuza » Fri, Aug 10, 2012, 2:17 PM UTC

dhimes wrote: post #6

Whoever 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…

"when ID needs change, and they will over the course of a project"

That sounds awfull like YAGNI would apply:

http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it

Re: Named Parameters in Java

#25

Post by erode » Fri, Aug 10, 2012, 2:19 PM UTC

I use named parameters in csharp, and they are nice, but they're not worth all that extra effort. The code is now much more confusing.

Re: Named Parameters in Java

#26

Post by TazeTSchnitzel » Fri, Aug 10, 2012, 2:23 PM UTC

nessus42 wrote: post #21

TazeTSchnitzel wrote: post #10

Earlier quoted context omitted.

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.

Named tuples are nice in Python. I wonder how easy it is, though, to modify a namedtuple constructor to do argument validation and to allow for default field values.

If you see how namedtuple is implemented, you'd realise it's extremely easy.

namedtuple uses eval(). It really shouldn't, since there are far better ways to do what it does, but it does.

Re: Named Parameters in Java

#27

Post by bad_user » Fri, Aug 10, 2012, 2:24 PM UTC

pathdependent wrote: post #19

Although 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 propos…

The problem with named parameters is that suddenly method parameters become part of your exposed API.

The other problem is that the compiler currently discards the parameter names, so older binaries are not going to be compatible.

Re: Named Parameters in Java

#28

Post by bchen » Fri, Aug 10, 2012, 2:26 PM UTC

Since long parameter list is considered a code smell, people should be discouraged from writing this kind of code anyways. Namely, this example from the article is in fact a bad practice:

> o.doSomething1("Alfred E. Neumann", "http://blog.schauderhaft.de, 42, "c:\\temp\\x.txt", 23);

As other commenters have pointed out, I think the builder pattern is one of the two solutions I would use. The other solution is to simply create an object that represents the values to be passed in to the method. Consider:

  User user = new User("Alfred E. Neumann");
  user.setLink("http://blog.schauderhaft.de);
  user.setUltimateAnswer(42);
  user.setTempFile("c:\\temp\\x.txt");
  user.setZip(23);
  o.doSomething(user);

Even with named parameters, I would say the latter approach is still superior than having a long parameter list.

Re: Named Parameters in Java

#29

Post by Aykroyd » Fri, Aug 10, 2012, 2:28 PM UTC

cpt1138 wrote: post #9

Wouldn't the Builder pattern address this issue? So you can do: object.setName("Alfred E. Neumann") .setLink(" http://blog.schauderhaft.de ) .setUltimateAnswer(42) .setTempFile("c:\\temp\\x.txt") .setZip(23);

That would definitely be a nicer way to do it. Although, using the builder pattern to create parameters for every single method in your API would be a gigantic pain.

Javascript APIs hack this in by taking Objects as params so that you can do {name='Alfred E. Neuman'...}. Unfortunately, Java's syntax isn't nice for creating Maps either, but maybe you could do something with that.

In the end, this seems like a problem with the language syntax and any fix other than one at the language level is going to be a hack.

Re: Named Parameters in Java

#30

Post by dhimes » Fri, Aug 10, 2012, 2:29 PM UTC

arethuza wrote: post #24

dhimes wrote: post #6

Whoever 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…

"when ID needs change, and they will over the course of a project" That sounds awfull like YAGNI would apply: http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it

There is a small but meaningful distinction: Encapsulating the data in OOP fashion allows you to respond when the need arises. You don't build it until you need it, but when/if you do ever need it you won't have to refactor the interface (and the interfaces of all the classes that use these data).

This minimizes changes down the road and leads to maintainability.