Homo Sapiens Abstractus

I have been writing some Hibernate code and in order to check what is going on with the mappings and the data they actually retrieve, all my domain objects implement org.ckkloverdos.string.IToStringAware of ckkl-core.

The actual domain model does not matter for this post, but let’s say that two of my classes are Person and Address and the association is such that a Person has one or more Addresses (under the hoods there are 3 tables, 2 for the entities and one join table). Also, an Address object has a reference to the Person it belongs to.

Here is a printout an Addresses list:

ArrayList[
  0=Address(
    name="Some address 1"
    person=null
    addressId=4)
  1=Address(
    name="Some address 2"
    person=null
    addressId=3)
  2=<REF:1>Address(
    name="The Master Address"
    person=Person$$EnhancerByCGLIB$$e8f89ce1(
      addresses=PersistentSet[0=<@REF:1>]
      name="The Master Person"
      personId=1)
    addressId=1)

...
]

So, actually, I can verify that I have one Person (”The Master Person”) to which one Address (”The Master Address”) belongs to. Notice how this Address lists its Person, which in turn has a circular reference to the particular Address.

Do not get confused by the domain object model. It actually does not matter. The idea here is that ToString can correctly report a circular reference in my object graph. It can also index those circular references in order of appearance, so that you will see <REF:1>, <REF:2> and so on, and of course the respective back-references <@REF:1>, <@REF:2> and so on.

<REF:n> marks a reference and <@REF:n> designates a circular (back) reference to the point where <REF:n> appeared. So, at the example above, we mark the particular Address having index 2 in the ArrayList because its object is also used in one of its properties, the Person.

One little bonus, as a side-effect of using the ToString mini-framework, is that I can see what Hibernate does under the hood, by noticing the name of the class

Person$$EnhancerByCGLIB$$e8f89ce1

Well, that’s nice!

I found the recent post of my friend Vassilios Karakoidas about Python rather stimulating, in the sense that it was a good opportunity for me to remember a little python after a long while…

The basic class definition in the above-mentioned post is:

class k:
  i = "foo"
  def get(self):
    return k.i

and the discussion in the post goes about the strange character of that ‘i’ attribute. Let me clarify things a little by providing some facts:

1. The ‘i’ is defined as a class attribute, meaning that all instances of the class see the same value for ‘i’.
2. Outside the class definition, you can access ‘i’ by simply typing ‘k.i’ without the need to create a new instance, as in ‘k().i’.
3. Python gives us the ability to create a new attribute for an existing instance on-the-fly, without having to define it in the class constructor.
4. If, probably by mistake or (as in the above post) on purpose, and according to fact 3, you decide to create an instance attribute with the same name as the class attribute, then the two ones co-exist and you need to be more precise when trying to access each of them.

With the rules above in mind. let’s play a little:

We print the value of the class attribute ‘i’, directly from the class:

>>k.i
'foo'

We create two instances and try to access the class attribute ‘i’ on both of them:

>> a=k(); b=k(); a.i; b.i
'foo'
'foo'

This is normal behaviour, since the class attribute ‘i’ is visible to any instance of the class. Now the tricky part: What if we try to change the class attribute ‘i’ via one of the instances, let’s say ‘a’:

>>a.i = 'foobar'; a.i; b.i;
'foobar'
'foo'

Oops!!! what hase gone wrong? Did we or did we not change ‘i’? Well, matters are simple. According to fact 3, what we actually did was to create an instance attribute with same name ‘i’ for the instance ‘a’. This creation of course, doesnot propagate to instance ‘b’! Now, for instance ‘a’, the instance attribute ‘i’ shadows the class attribute ‘i’, which of course we have not changed and remains the same:

>> k.i
'foo'

According to fact 4, in order to be able to access both the class attribute and the instance attribute, we just need to be more precise:

>> a.__class__.i
'foo'
>> a.i
'foobar'

And, by the way, did you notice that Python lets you write more that one statement in a line?

One of the reasons I created org.ckkloverdos.collection.L, is to be able to adopt a more declarative style of programming, since this collection/array wrapper class makes it easy to do some functional-oriented programming.

The other day, I was playing around with the API of Package. At one point, I just wanted to see the loaded packages from my own ckkl-core library. The implementation, using L, is both simple and I believe elegant:

new L(Package.getPackages())
  .selectProperty("name")
  .filterStartsWith("org.ckkloverdos")
  .print();

What would be the alternative in plain-old-Java?

Package[] packages = Package.getPackages();
for(int i = 0; i < packages.length; i++)
{
  String name = packages[i].getName();
  if(name.startsWith("org.ckkloverdos"))
  {
    System.out.println(name);
  }
}

I have decided to host ckkl-core to google now. Probably I will keep posting the releases to sourceforge as well but I have not definitely made my mind on that yet. Anyway, the new page is here. The latest release is 0.3.1.

Today, I released jBootstrap at google.

Have you been tired of continuously (re)adjusting the CLASSPATH when developing a new application/library? Have you been tired of issuing ever increasing “export CLASSPATH/set CLASSPATH” statements in your shell executable that fires-up your application?

Then jbootstrap can take your headaches away. Just gather all your JAR dependencies under one directory and run your application by simply specifying this directory. jbootstrap will pick up the JARs, create an appropriate classloader and fire-up your application instantaneously.

[or: Abstractions are not born abstractly]

Being in the software research and business for about ten years now, and while trying to invent and build flexible software architectures, one (meta-) idea is always recurring in my mind: That you need to have enough concrete input in order to produce an abstract output.I am, of course, referring to the development of software engineering abstractions.

While looking at the history of maven earlier this morning, I was delighted to come across to this saying, attributed to Ralph Johnson and Don Roberts:

People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a reusable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be.

How well put, really! You cannot just develop abstractions directly, unless you talk directly to God, if you allow me to exaggerate a little.

It is generally accepted that abstractions are used to reduce software complexity. In my opinion that is only one part of the truth or, to be more precise, it does not reveal the essence. I believe that the real essence of abstractions is that they allow you to view the structure (or “meaning”, if you prefer a rather philosophical tone) of things in a clearer and deeper way. And this is what leads us to first understand and then deal with complexity.

And since I am in the consulting business, I cannot but comment on the fact that some people find it very hard to grasp the whole process of constructing abstractions and/or the domain a particular set of abstractions can be applied in. I wouldnot want to elaborate on this, at least not for now, but I have the feeling that they just do not get it. In my opinion, they are either under-experienced or under-educated. I would definitely recommend a little science history reading