I'll start with a one sentence summary of the greater Seattle area; Like Sweden, but bigger.

To elaborate, pretty much everything is bigger over there. The trees are bigger, the mountains are bigger, the cars are bigger, the stadiums are bigger and more numerous, the streets are wider, and the food portions are more generous. While we also have trees, mountains, cars, stadiums, streets and everything else they have over there, theirs are simply bigger. Whether that is positive or negative depends on the question at hand, and I guess I can't give a much better generic answer than "it depends".

The second most obvious thing I've noticed about Seattle is that people are more relaxed, hospitable, and easy-going. They are simply just very nice. Nicer than Swedes, I would say, at least on a shallow level. But when you think about how many people you talk to on any given day, you realize that you actually have a lot of rather shallow conversations. Americans are just so much better than Swedes at having those casual and spontaneous conversations. In fact, if there is one thing I would like to bring back home to Sweden, it would be this very skill.

One of the absolutely best things I did in Seattle, possibly even the best, was to start playing Ultimate. I've met a whole bunch of cool Americans, I've learned a great sport, and I've had so much fun! Not to mention that it has helped me stay in shape, and not gain any weight. I can wholeheartedly recommend both Ultimate as a sport, as well as playing some kind of team sport while studying abroad. It's a great chance to meet new people.

Also, I'm happy I took the chance to travel as much as I did. I've visited Hawaii, Las Vegas, Florida, Olympic Peninsula and California. During some trips, I either visited someone I knew, or had a visitor, which made them extra fun. Although I've spent thousands of dollars on these trips, I don't regret traveling for a second. The places I've visited are places I would have wanted to visit sometime in my life anyway, and why not do it when you've already paid for the trip over the Atlantic anyway? However, as a word of advice, don't forget to [bring a towel->http://www.bbc.co.uk/cult/hitchhikers/guide/towel.shtml]!

So, finally, for any and all of you out there - if you have the chance to study abroad, do it! For some reason, most people who have studies abroad tend to say that it was one of the best times of their lives, and that don't regret it. Although it might sound as a cliché, I can't help but chime in. Do it! You will have a great time, and you won't regret it.

Over and out, Henrik

To reward myself I just went down to my favorite Greek restaurant, sat down and had a nice dinner including almond baklava for dessert. Really good! As I've been to that restaurant on more than one occation, I've got to know the owner a little bit. So he was sad to hear that I was leaving (I guess I was a good customer). He also gave me his email address and asked me to write him a letter sometime. Great to know that at least someone is going to miss me.

Now it's about 15 hours until I should be at the airport, and the "only" things I have to do before that is pack my suitcases and sleep. Sounds easy, right? Let's hope for my sake that it is.

All cards feature one of the members of Bush's staff and gives a nice quote or a brief description of the person. My "favorite" so far is probably Karen Hughes, Under Secretary of State, Public Diplomacy and Public Affairs who made a "solid" connection between the 9/11 tragedy and of all things abortion by saying.

I think that after September 11, the American people are valuing life more, and we need policies to value the dignity and worth of every life. […] I think those are the kind of policies the American people can support, particularly at a time when we're facing an enemy.

I am speechless.

I want to get rid of my room! I was making the room look all nice and shiney because today at 10am I was supposed to show the room to a girl who was interested in renting it. But when I came back to my room about 9:50am after taking a shower, I had a voice mail on my phone from her saying that she wouldn't come after all.

Too bad, but at least my room is a lot cleaner!

Well, not much you can do about it.. (besides putting some ice on it, but I was too lazy to get some). I continued playing. Towards the end of the game, I was running for the disc and just about to score when one of my team mates (who was also going for the disc) accidentally macked it right into my face. On my upper lip, to be more precise. Bam! That hurt, again! It's going to be even more beautiful tomorrow.

After this, I actually convinced myself to go get some ice to put on my lip. I don't know how much it helped, I might have been to late, but it's better than nothing I guess.

Show this on a map.

UPDATE: I managed to incorrectly make the first link point to the wrong place. Now fixed.

This time, the TGIF was a bit bigger, and took place at a lawn behind the CSE building. There were free burgers, hot dogs, soda and beer, as well as a number of ways to entertain oneself. Most notably a huge inflatable erm, thing, in lack of a better word, where two combatants joined by a rope were trying to put small basket balls in baskets as far from each other as possible. Another inflatable large thing allowed two people (with helms) to nock each other off small platforms with huge (but rather soft) clubs. The third and perhaps most popular thing was the hit-the-bullseye-with-a-ball-and-make-the-person-sitting-over-the-pool-fall-down-into-it thing. The people sitting there, waiting to be thrown into the water, were teaching assistants, staff and faculty. Even the chair of the department got his time. To the amusement of the crowd, the first person who managed to make the old chair (who also happens to be teaching one of the classes I'm currently taking) fall down into the water, was his about 5 year old daughter.

I also brought my faithful frisbee to the party, and it got used pretty heavily. Unfortunately, it was ran over by a car earlier on the day, so it was slightly cracked. But it worked pretty well anyway. A couple of us ended up staying for a few hours playing Ultimate in the slightly wet grass. It was very informal, very fun, and my pants are now very, very dirty.

Show this on a map.

Two ways to see it

Some say that it should be done using the instanceof operator, like this.

public boolean equals(Object obj) {
    if (obj instanceof MyClass) {
        MyClass that = (MyClass) obj;
        // compare this and that
    } else {
        return false;
    }
}

Other says that it should be done by comparing the exact classes of the two objects, like this.

public boolean equals(Object obj) {
    if (obj != null && obj.getClass() == this.getClass()) {
        MyClass that = (MyClass) obj;
        // compare this and that
    } else {
        return false;
    }
}

The difference lies in how they treat subclasses. As instanceof returns true if obj is of the same class or any subclass, it will allow subclasses to be considered semantically identical to their superclasses. Comparing the result of getClass() on both objects will require that they are of exactly the same class. Using that method, no subclass can ever be semantically equal to its superclass.

To understand why this difference matters, it is important to remember one of the requirements Java has on any implementation of equals(); the equality relation must be symmetrical. In other words, for any objects a and b the expression a.equals(b) may return true if and only if b.equals(a) also does.

Because of this, the getClass() camp argues that since we can't predict how subclasses might want to implement equals(), we better implement equals() in such a way that it only compares objects of the same class. That way a subclass can safely override and implement equals() any way they want. For example, a subclass might have additional fields which it wants to use in the equality comparison. Otherwise we might end up in a situation where e.g. the superclass says that is equal to the subclass but not the other way around.

The argument from the instanceof proponents is that not allowing a subclass to be considered equal breaks the notion of [polymorphism->http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming]. It also violates the [Liskov substitution principle->http://en.wikipedia.org/wiki/Liskov_substitution_principle] as well as the [principle of least astonishment->http://en.wikipedia.org/wiki/Principle_of_least_astonishment].

How I see it

Okay, enough with the summary. Now I'll throw my own two cents in.

I think this whole question pretty much falls apart if we just make a better distinction between interface and implementation. An interface decides what a method is supposed to do, while a particular implementation knows how to do it. In other words, it is up to the interface to define what equality means for that interface. Being separated from its implementation(s), the interface must therefore define equals() in terms of comparisons of its own members. Thus, it cannot require the other object to "be of the same class" without having inappropriate knowledge about at least one of its implementations.

One problem is that a class in Java is somewhat ambiguous as it both has an interface and provides an implementation for it. This makes the interface more implicit. If you think it makes things clearer, extract an interface from your superclass and let it define (through documentation and unit tests) the exact behavior of the implementation. Then implement that exact behavior in any way you see fit in your class.

Example: Collections in Java

A good example of how things should work is the collections framework in Java. If we look at the documentation for the equals() method of e.g. the [Set->http://java.sun.com/j2se/1.5.0/docs/api/java/util/Set.html] interface, we see the following. Pay special attention to the last sentence.

Returns true if the specified object is also a set, the two sets have the same size, and every member of the specified set is contained in this set (or equivalently, every member of this set is contained in the specified set). This definition ensures that the equals method works properly across different implementations of the set interface.

This behavior is defined by the interface [Set->http://java.sun.com/j2se/1.5.0/docs/api/java/util/Set.html]. It is then implemented in the abstract class [AbstractSet->http://java.sun.com/j2se/1.5.0/docs/api/java/util/AbstractSet.html] which is in turn extended by [HashSet->http://java.sun.com/j2se/1.5.0/docs/api/java/util/HashSet.html] and [TreeSet->http://java.sun.com/j2se/1.5.0/docs/api/java/util/TreeSet.html]. None of the two subclasses override equals().

Example: Employees and Managers

In a blog entry, Cay Horstmann uses [another example->http://www.artima.com/weblogs/viewpost.jsp?thread=4744]. However, he is arguing for using getClass() rather than instanceof. His example includes a class hierarchy where we have an Employee class as the base and then a Manager class which extends Employee by adding a bonus field. Expressing the example in code, it would look something like below.

public Employee {
    // ...
    public boolean equals(Object other) {
        if (!(other instanceof Employee)) return false;
        // cast other to Employee and compare fields
        // ...
    }
}

public Manager extends Employee {
    // ...
    public boolean equals(Object other) {
        if (!super.equals(other)) return false;
        // cast other to Manager and compare fields
        return bonus == ((Manager)other).bonus;
    }
}

In other words, the subclass Manager changes the meaning of equality it inherited from its superclass Employee. Is this a sensible thing to do? As you might guess, I would say no. We (hopefully) decided when we wrote Employee that there was a given way to uniquely identify any specific employee. That might have been an employee id, combination of first name and last name, or any other combination of Employee members. For sake of discussion, let us say we compare the values of the function getId(). Being an Employee itself, what reason would Manager have to change this definition? To check if two Manager objects have the same id but different values for the field bonus? Well, if we do have two such objects, then that is the problem. We shouldn't have allowed them exist at the same time. The job of equals() is not to guard us from having corrupt data in our model!

Final thoughts

If a subclass truly has to override equals() to provide a semantically different implementation of equals() it might instead be a sign of that the subclass perhaps should not be a subclass after all. A subclass is supposed to extend or alter the behavior of a superclass or implement the behavior of an interface, but always doing so within the boundaries of all inherited interfaces.

One way to make sure subclasses does not break the contract is to make the equals() method in the superclass final. However, I think that is just overly protective. There could be a valid reason for wanting to override the equals() and still preserve its semantics. Performance optimization could be one such reason.

Thus, in my humble opinion, the correct way to implement equals() is as follows.

public boolean equals(Object obj) {
    if (obj instanceof MyInterface) {
        MyInterface that = (MyInterface) obj;
        // compare public members of this and that
    } else {
        return false;
    }
}

However, my opinion might not be the same as yours, and your opinion might not be the same as mine (for symmetry purposes ). If you happen to have another opinion, feel free to comment or trackback!

As a sidenote, I have found a [potential Master's Thesis->http://www.ce.chalmers.se/org/position/open/MindValue_(2).pdf] ("ex-jobb") at MindValue, a [Chalmers School of Entrepreneurship->http://www.entrepreneur.chalmers.se/] startup. We've got a meeting set up for when I come back to Gothenburg to discuss the work. Until then I don't know more than the linked-to document tells me, and they don't know more about me than my letter and CV told them. So in about two months we'll see if it is a match.

Vädergudarna var helt klart på vår sida denna dag, solen stod högt på himlen och ett par solglasögon hade verkligen inte suttit i vägen. Stigarna var fina och naturen som sagt magnifik, ju högre upp man kommer desto bättre blir utsikten mot berget och dess glaciär. Större delen av vandringen går stigen längs med Carbon River viket ger en fantastisk utsikt mot de omkringliggande bergen. Strax innan vi nådde fram till Carbon Glacier korsade vi vattnet via en hängbro.

Väl uppe vid glaciären tyckte vi den såg väldigt liten ut och efter att ha gått runt lite för att kika närmare bestämde oss för att äta vår medhavda matsäck. Under tiden vi åt satt jag och tittade ner mot vad vi först identifierat som en bergvägg och inser till sist vårt misstag. Vi hade på grund av allt grus som satt fast i ytan på isen misstagit den relativt stora glaciären för ett berg. Då vi äntligen insett detta valde vi att klättra en smula utanför ledan och ta oss ner till smältvattentunnelns utlopp från glaciären. Det kändes ganska imponerande att stå såpass nära en glaciär, men medans vi stod där damp det ner sten i en väldig fart en 10-15 meter från oss. Då insåg man lite varför det inte är rekomenderat (läs förbjudet) att gå ner till glaciären och vattnet.

Efter detta begav vi oss tillbaks till bilen för att ta oss tillbaks, på vägen tillbaks såg vi dock ett vattenfall skymta fram mellan träden och stannade därför. En kort promenad så var vi precis vid vattenfallets nedre del, det var väldigt fint med härligt ljus som kom mellan träden, en mycket bra avstickare. Efter denna lilla avstickare åt vi resten av vår matsäck och begav oss sedan tillbaks till Seattle för att lämna tillbaks hyrbilen.

/Göran

Show this on a map.