Infrequent Update

Monday, May 01, 2017

Common misconceptions about immediate values in Ruby

Immediate Values

Frequently you can read in Ruby discussions sentences like "You cannot do X because Y is an immediate value". Or: "You must (not) use immediate values for Z."

If you do not know what immediate values are, here is the brief explanation: immediate values in Ruby are an implementation of tagged pointers. This means, that pointers for all Fixnum values, true, false and nil do not point to objects on the heap but are self contained. This is an internal optimization of MRI which saves memory and speeds up certain math operations because they do not require memory allocation (and thus no bookkeeping for GC and, of course, no GC either).

Now I told you too much already, because for programming Ruby this is - irrelevant. Of course, there are the optimization effects mentioned above, but beyond that immediate values have no effect on how you write your Ruby programs. Heck, you cannot even notice whether something is an immediate value or not in a Ruby program!

Now, some of you might say, "Wait, there are certain things I cannot do with immediate values, i.e. I cannot change them!". Well, that is true (except for when it was possible to add instance variables to Fixnums, e.g. in 1.8.7) but there are more immutable objects around, namely Symbol and every object that you have frozen. The important distinction is between "mutable" and "immutable" objects, not between "immediate values" and "regular objects" because only this is noticeable and has effects on a programs working.

If you do not believe this you can try to write a function is_immediate(obj) in Ruby which returns a trueish value iff obj is an immediate value without resorting to your knowledge about which types have immediate values. You can also think about what lines of code you would have to change in your Ruby programs if Matz decides tomorrow to put all Fixnums on the heap.

Where it came from

I assume that since Fixnums, true, false and nil are immediate values and immutable people tend to assume that the immutability is somehow closely tied to immediate values. And it is reasonable to expect immediate values to be immutable because there is no place in memory to store state (at some point in time I need to dig into how it was done in 1.8.7).

But: objects can be immutable without being immediate values, this is not a requirement. Any object that does not have state modifying methods is immutable. It can have as much state as it likes to have as long no client can change it.

Ruby's math operators like +, -, * and / work in a way that you must keep the return value because most often you get a reference to another object back. Some people might be led to believe that in Ruby there is inplace modification of math values because there is operator +=. But x += 2 is really only syntactic sugar for x = x + 2. (Note that this was a very wise decision of Matz because that allows a seamless transition between numeric types; if you keep multiplying a Fixnum value by two you will inevitable get a Bignum at some point in time.)

Conclusion

Yes, there are immediate values in MRI. No, they do not have effects on the logic and functionality of your program, they are indistinguishable from other object references. They still do have their value (pun intended) but when reasoning about why a particular program needs to be or can be written in a certain way, think about mutability vs. immutability - not some arcane optimization of the interpreter.

Labels: , ,

Friday, August 31, 2012

Better approach to make hashing in Java more flexible

Today I received the newsletter from www.javaperformancetuning.com which covers a recent change in the implementation of hash tables in Java. They claim "The generic way to do this" (meaning, providing a custom hash function other than what Object.hashCode() and overridden versions provide) would be to define an interface Hashable with a new method hash() defined. However, there is an easy approach available which is much more flexible:

/**
 * This interface abstracts algorithms used
 * for hash structures.  Implementations
 * must observe the proper contract (i.e.
 * if {@link #equals(T,T)} returns
 * <code>true</code> {@link #hashCode(T)}
 * must return identical values for both
 * instances).
 */
public interface HashAlgorithms<T> {

  /**
   * Calculate the hash code for the given instance.
   *
   * @param object any object, may be <code>null</code>
   * @return the hash code.
   * @see Object#hashCode()
   * @see Object#equals()
   */
  int hashCode(T object);

  /**
   * Compare two instances for equality.
   *
   * @param a any object, including <code>null</code>.
   * @param b any object, including <code>null</code>.
   * @return <code>true</code> if both instances are considered equal.
   * @see Object#hashCode()
   * @see Object#equals()
   */
  boolean equals(T a, T b);
}

By having this and of course changing java.util.HashMap and the like to accept an instance of this interface at construction time it is immediately obvious that we would not need class IdentityHashMap.

Why did nobody think of this?

Tuesday, December 29, 2009

Do we want to trade imagined security for real freedom?

Current discussions revolving around the recent airplane terrorist attack remind us how politicans work: as soon as something happens (or nearly happened as in this case) politicians are immediately jumping to conclusions and everybody wants to be the first to propose new "security" practices. That's a good time to remind ourselves what bad practice that is. Bruce Schneier did it excellently in a recent article. Mind you, I'm all for security but measures which largely increase inconvenience and decrease personal freedom but do not really add to our security should be abandoned. Otherwise terrorists will win because we will change the way we live and become more distrusting and locked up. Our western societies need to ask themselves whether this is the direction to go!

Labels: , ,

Thursday, January 17, 2008

Nokia leaves Bochum

The decision to close the plant in Bochum has stirred up a heated debate over here in Germany. I find the media's exaggerations do the issue no good. Some politicians claim that Nokia does a kind of "rude stoneage capitalism". That's not exactly true. Apparently they found that they can make more money by assembling their mobile phones elsewhere.

However, when asked the management did not really come up with convincing monetary arguments. Also, it seems the way they informed their employees in passing by violated their own company policies. In the end, they did not do themselves a favor...

I do not think this is a case for intervention from official sides, unless it turns out that Nokia actually receives public money to open plants and close them again. That would indeed be a bad situation. And it sheds some light on the usefulness of public money subsidies...

Labels: ,

Wednesday, May 16, 2007

New Orleans - again

Almost a year later than I last wrote about New Orleans things seem to get better only very slowly. And it seems, once again the hard working people are the ones who suffer most - despite all the rhetoric that stresses their importance for the country. It's sad.

Labels: ,

Tuesday, October 10, 2006

Anna Politkowskaja

The assassination of Anna Politkowskaja is a tragedy and a scandal. And what happens afterwards is another scandal itself. Putin assures "everything [will] be done to clear up the murder" and states "She (Politkowskaja) had minimal influence on political life in Russia". This raises severe questions:
  • Is it not normal in Russia that everything is done to find and punish killers?
  • How can Putin make this promise? Can he influence the work of prosecution authorities?
  • Is justice independent in Russia?
  • Is the murder less outrageous because a less influencing journalist was killed?
  • Or did Putin maybe state that her influence was minor because he disliked her criticism?
It becomes more and more apparent that Putin's notion of "democracy" differs largely from the one Europe and the US share. With all the efforts to mute criticism and to "reintegrate" former Warsaw Pakt countries into the Russian empire we should keep this difference in mind and remind Russia from time to time to try harder to find the way to democracy. Also, it seems a bad idea to make ourselves more dependend from Russia than necessary such as German soccer team Schalke 04...

Labels: ,

Thursday, August 31, 2006

What's happening in New Orleans?

It's difficult to keep track of things from a distance. There are different pieces of information, some suggest that certain people try to get rid of part of the population, others suggest that there's actually some progress in rebuilding the city. Most seem to agree, that official institutions failed not only when Katrina raged through Luisiana but also in the year since then. It seems, that involved parties do not focus on the city and its (former) inhabitants but use the situation to play their own games.

I hope for the inhabitants of New Orleans who are spread throughout the country that they eventually be able to return to their homes - and that measures are taken which prevent the reoccurrence of such dramatic catastrophes.

Labels: ,

Wednesday, August 30, 2006

Uh, I'm there


Just to set everybody's expectations right: I can't promise to do frequent updates. We'll see how I do over time...

My areas of interest:
  • Software Engineering
  • Digital Photography
  • Cats
  • Politics
  • etc.
Have fun!

Btw, of course that's not me - it's Tyron at his laziest. :-)