Named Parameters in Java • Hacker News Board

Re: Named Parameters in Java

#31

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

SeanLuke wrote: post #23

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.

It may be "fake", but it still has the property that this article was looking for, in that it is obvious to the reader what each of the arguments being passed to the method are for.

Re: Named Parameters in Java

#32

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

columbo wrote: post #8

Interesting. But it looks like it is solving a problem with another problem. The receiving class would then look like this: public void doSomething(Name name, Link link, UltimateAnswer ultimateAnswer, TempFile tempFile, Zip zip) { String name = name.name; String link = link.link; int ultimateAnswer = ultimateAnswer.ultimateAnswer; String tempFile = tempFile.tempFile; int zip = zip.zip; } If the problem is "I don't li…

I'm not sure I see the "another problem" you're referring to. Can you describe the problem with the new implementation of doSomething()?

Also, I don't think the original problem was the same values being used all over the place. The problem is how to be clear about which parameters you're providing, and accepting static types and giving the type a simple way of constructing it solves that.

Re: Named Parameters in Java

#33

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

peeters wrote: post #22

nessus42 wrote: post #17

Earlier quoted context omitted.

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?

I've heard the Law of Demeter at times stated explicitly as that you should usually return only primitive data types from an API. Rich Hickey certainly claims this too, although he doesn't refer to it as the Law of Demeter.

The Law of Demeter is also sometimes summarized by "One dot: good. Two dots: bad."

Or from Wikipidia:

In particular, an object should avoid invoking methods of a member object returned by another method. For many modern object oriented languages that use a dot as field identifier, the law can be stated simply as "use only one dot". That is, the code a.b.Method() breaks the law where a.Method() does not.

Edit: I should have written "built-in types" above, rather than "primitive types".

Re: Named Parameters in Java

#34

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

PaulHoule wrote: post #2

It might be crazy but I like this kind of DSLization of Java a lot

I've seen a pretty big move in popular libraries to fluent interfaces. It does a pretty good job of getting over the verbosity in Java (at least where the verbosity hurts readability).

Examples like Guava:

   Cache userCache = CacheBuilder.newBuilder()
      .initialCapacity(7)
      .expireAfterWrite(20, TimeUnit.MINUTES)
      .build();

Or Hamcrest:

   assertThat(result, containsString("OK"));

Or Rest-Assured:

   expect().statusCode(200).when().get("/user/1");

Re: Named Parameters in Java

#35

Post by moondowner » Fri, Aug 10, 2012, 2:34 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);

or ObjectName.getBuilder("Alfred E. Neumann", "http://blog.schauderhaft.de, 42, "c:\\temp\\x.txt", 23).build(); maybe?

It's not addressing named parameters issue, but I find it better like this.

Re: Named Parameters in Java

#36

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

jebblue wrote: post #16

x3eme wrote: post #11

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

I think there's a kernel of truth to that but it's not entirely right. I use Pycharm for my python coding and still like named parameters because it makes clear at a glance what each parameter is in the function call. Otherwise, I'd need to click through to each function definition or use the "show doc" command to figure it out. It's much better to be able to scan through the code and understand it without intervention from IDE features.

Re: Named Parameters in Java

#37

Post by yarrel » Fri, Aug 10, 2012, 2:37 PM UTC

bchen wrote: post #28

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

Named parameters would result in more readable, compact, and efficient code compared to the latter approach.

But yes, long parameter lists (whether represented as argument structs or not) generally indicate a problem.

Re: Named Parameters in Java

#38

Post by [deleted] » Fri, Aug 10, 2012, 2:39 PM UTC

nessus42 wrote: post #33

peeters wrote: post #22

Earlier quoted context omitted.

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

I've heard the Law of Demeter at times stated explicitly as that you should usually return only primitive data types from an API. Rich Hickey certainly claims this too, although he doesn't refer to it as the Law of Demeter. The Law of Demeter is also sometimes summarized by "One dot: good. Two dots: bad." Or from Wikipidia: In particular, an object should avoid invoking methods of a member object returned by another…

[deleted]

Re: Named Parameters in Java

#39

Post by hnriot » Fri, Aug 10, 2012, 2:44 PM UTC

bchen wrote: post #28

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

This, like many of the proposed solutions here exposes the issue that putting the (not particularly) long list of parameters into the ctor, that of not every being able to call doSomething without all the required values. What is the caller of your builder doesn't remember to set the zip and the doSomething method then uses it? You've only really added syntactic sugar and sacrificed functionality.

Re: Named Parameters in Java

#40

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

dhimes wrote: post #30

arethuza wrote: post #24

Earlier quoted context omitted.

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

But it also means that you are introducing a lot of extra classes that do almost nothing but wrap primitives and provide little or no additional behaviour.

If you do need to pass in additional information, refactor and change the primitive to an object when you really need to, not because you might need it at some point in the future (and the chances are you won't).