Fig: Java elegant supplement | Hacker News Reader

Fig: Java elegant supplement

wapatesh.github.io

43 pointsganqiongzi14 comments

A convenient addition the library would be a Seq/Hash that delegates to a "regular" List or Map without copying. I haven't had the time yet to look into how default interface methods work in conjunction with dynamic proxies, but may be able to easily "figify" a list that way

"Fig uses conventions on method names similar with Ruby. If there is a pair of methods name, name$, method ends with $ means calling this method will change the object itself, while calling the other won't."

This seems very un-Java - surely the Java way to achieve this would be method overloading.

I do agree that this is very un-Java. However, how would method overloading allow for the simple given example of shuffling a sequence?

    seq.shuffle(); // copy to a new seq and shuffle it
    seq.shuffle$(); // shuffle the original seq

These two methods should have the exact same signature. So using two different names is necessary. I'm not particularly fond of introducing $ as a substitute for !. That convention is not existent in Java, and is not at all obvious to anyone who hasn't studied a functional language.

I would probably solve this by simply making shuffle always in place, and add a copy constructor and/or copy method:

    // Copy and shuffle.
    (new Seq(seq)).shuffle();
    seq.copy().shuffle();

    // Shuffle in-place.
    seq.shuffle();

While I also recoil at the $, I much prefer a functional programming style based on immutable objects. Defaulting to in-place mutation would ruin the API.

I probably would have gone with shuffleInPlace(), but the more I think about it, the more I like the $. Especially since it will rarely get used.

This library is pretty neat largely because it changes some common (and annoying) java idioms.

In that case, have shuffle() always return a new copy, and there is no in-place shuffle. I would consider this a good solution, assuming that the loss of an in-place shuffle is acceptable. (This would basically be the .NET LINQ approach.)

For a really class act, check out Ceylon's collection classes. As an example, Set and SetMutator are separate interfaces; a MutableSet has both. The whole standard library is really well thought out WRT typesafe functional programming.

Agree this would be the idiomatic java way to do it.

I would greatly prefer this approach - it is clear, consistent with common java practices, and self-documenting: you don't even really need to know java to understand what this does.

You're right, with method overloading you would need to add something to the signature to indicate that one variant works in place - and that would be nasty. Your solution is nice.

Great opinion.

I do agree $ is very un-Java, either.

But I don't want "shuffle" to be in-place method by default. I agree with @jdmichal that it should return new copy.

In this case how to design the in-place way is not obvious.

I'm the main author of fig. This project is started for just a week. All of your suggestion are very supportive and I'm checking the feedback to make fig better.

I would simply not have in place modifiers. Focus your programming efforts instead on adding other cool high level constructs on lambdas.

See underscore or scala for inspiration.

You could take a page from Scala's book and create separate immutable and mutable versions, e.g. Seq vs Queue.

I wonder why they didn't just use ! like Ruby does? Is that not allowed in Java? I always mentally say the ! version of a method like a real exclamation (oh no! save!) to make sure I realize it's going to change something. Using $ just seems random.

Actually, yes, '!' is not allowed in Java identifier.

Method overloading depends on the method signatures being different, but in this case the methods differ only in name.

Reply on news.ycombinator.com