Indeed, your example appears striking. I haven't worked with Scala, but I've been coming back to it and reading up on it at a leisurely pace. This example made me want to dig a little deeper and see what's what.
Well, as it turns out, according what I've come across so far (I didn't get a chance to inspect the Scala generated classes yet), it seems the behavior will not be equivalent. One big difference is that apparently Scala case classes implement equals using instanceof rather than getClass approach in your Java implementation. This may never matter to you, but I did find some interesting ways to make case classes do weird things (http://blogtrader.net/dcaoyuan/entry/ scala_corner_case_3_object). Now, whether getClass or instanceof is a better solution should probably be a separate debate, but I'd say that switching to instanceof would make things a little more terse. Another thing I'd like to point out is that I've found myself implementing a little utility method I call equalsOrNull, which goes something like this: public class Util { public static boolean equalOrNull(Object o1, Object o2) { if(o1 == null) return o2 == null; return o2 != null && o1.equals(o2); } } I do this both in Java (works well in GWT as well) and BeanShell (Groovy's grandpa) and it cleans things up considerably. I'm a bit confused by your hashCode implementation. I'm not familiar with how Scala does it under the covers, but in your example, you seem to just add 31 to name's hashCode output. Perhaps this isn't the best way, but I've always just xor'ed member fields' hash codes and that was that. If you really need a stronger hashCode implementation, I was just thinking how storing fields in a collection might help both equals and hashCode. Something like this (yes, it's not pretty, but it's relatively terse): public class WhatAmIDoing { private final List<Object> fields; private final String name; private final int age; private final boolean crazy; public WhatAmIDoing(String name, int age, boolean crazy) { this.name = name; this.age = age; this.crazy = crazy; this.fields = Arrays.asList(name, age, crazy); } public int hashCode() { return this.fields.hashCode(); } public boolean equals(Object other) { if(other == this) return true; // Note: equals contract doesn't mandate checking other's nullness return other instanceof WhatAmIDoing && this.fields.equals(((WhatAmIDoing)other).fields); } // Yes, we still need to write accessors by hand. } On May 6, 4:22 am, Viktor Klang <[email protected]> wrote: > On Wed, May 6, 2009 at 3:37 AM, Alexey Zinger <[email protected]> wrote: > > > This is gonna be about verbosity of generics, isn't it? > > Hi Alexey! > > The switch to Java 5 certainly added alot of cruft for API developers with > regards to the addition of Generics. > But this is not about Generics, this is about all the small things adding up > - turning Java into a boilerplatey language when building abstractions/APIs. > > When I switched from Java to Scala, I suddenly noticed a rather striking > difference: In Java there's alot of "supporting" code; and in Scala, there > is alot less. > This means that you spend less time writing code, and more time thinking > about the solution. > > Compare: > > Scala: > > *case class Person(var name : String)* > > Java: > > *public class Person > { > public Person(String name) > { > super(); > this.name = name; > } > > private String name; > > public String getName() > { > return name; > } > > public void setName(String name) > { > this.name = name; > } > > @Override > public int hashCode() > { > final int prime = 31; > int result = 1; > result = prime * result + ((name == null) ? 0 : name.hashCode()); > return result; > } > > @Override > public boolean equals(Object obj) > { > if (this == obj) > return true; > if (obj == null) > return false; > if (getClass() != obj.getClass()) > return false; > Person other = (Person) obj; > if (name == null) > { > if (other.name != null) > return false; > } > else if (!name.equals(other.name)) > return false; > return true; > }} > > * > > While the above is just a trivial example, it would think it accentuates my > point. > > I spent a couple of hours the day before yesterday rewriting an event > dispatch API in Java, trying to expose the most clean consumer interface as > possible, and I really felt I had to jump through hoops in order to be able > to do just that. But when written in Scala, not only was the resulting API > code about 30% of the LoC, but it also exposed a _cleaner_ interface. > > That's when the question to write libraries in Scala to be consumed by Java > application code. > Hence this thread. > > Viktor > > > > > > > Alexey > > > --- On Tue, 5/5/09, Dave Watson <[email protected]> wrote: > > > > From: Dave Watson <[email protected]> > > > Subject: [The Java Posse] Re: Java as API language, its days numbered? > > > To: "The Java Posse" <[email protected]> > > > Date: Tuesday, May 5, 2009, 9:10 PM > > > What does this mean, exactly? Can you elaborate more about > > > the 85% of > > > your code that is boilerplate? > > > > Not trying to argue, I'm just very puzzled by what this > > > might mean.... > > > > On May 5, 5:27 pm, Viktor Klang > > > <[email protected]> wrote: > > > > Greetings posse, > > > > > having spent more than half a decade writing API:s in > > > Java I feel that since > > > > Java 5 was introduced, more and more time has to be > > > spent writing > > > > boilerplate API code to try to save the API consumers > > > from jumping through > > > > hoops in order to get stuff done. Because we all want > > > easily consumable > > > > libraries, don't we? > > > > > Having jumped onto the Scala bandwagon about 1½ years > > > ago I feel like the > > > > ratio of business end code of Java is appro 15% while > > > in Scala it's more > > > > like 65% > > > > > <observation>You can most likely substitute > > > "Scala" in the text below with > > > > any non-Java JVM language</observation> > > > > > With Scala getting more and more cleaner to be > > > consumed by Java code, isn't > > > > there plenty of good reasons to switch to Scala for > > > library code, while > > > > letting the application developers stay i Java-land? > > > > > -- > > > > Viktor Klang > > > > Known from the Internet > > -- > Viktor Klang > Senior Systems Analyst --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
