"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();
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.
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.
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 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.
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
15 comments
[ 2.7 ms ] story [ 42.1 ms ] threadThis seems very un-Java - surely the Java way to achieve this would be method overloading.
I would probably solve this by simply making shuffle always in place, and add a copy constructor and/or copy method:
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.
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.
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.
See underscore or scala for inspiration.