4 ms·
"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
by bshimmin 11y ago
"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.
- pohl 11y agoMethod overloading depends on the method signatures being different, but in this case the methods differ only in name.
- jdmichal 11y agoI 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();
- cmicali 11y agoAgree 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.
- bshimmin 11y agoYou'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.
- stickfigure 11y agoWhile 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.
- jdmichal 11y agoIn 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.)
- stickfigure 11y agoFor 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.
- liuyang1204 11y agoGreat 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.
- ramblerman 11y agoI 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.
- ARussell 11y agoYou could take a page from Scala's book and create separate immutable and mutable versions, e.g. Seq vs Queue.
- MattGrommes 11y agoI 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.
- liuyang1204 11y agoActually, yes, '!' is not allowed in Java identifier.