On Wed, May 6, 2009 at 4:58 PM, Alexey <[email protected]> wrote:
> > 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<http://blogtrader.net/dcaoyuan/entry/%0Ascala_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. The Equals/hashCode implementation was produced by Eclipse 3.4 (historically I've built utility equals/hashcode/toStirng/compareTo based on Lists/arrays of attributes just as you suggested below) > > > 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 > > > -- 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 -~----------~----~----~----~------~----~------~--~---
