The Perils of Meta « Speaking my mind

The Perils of Meta

An age ago there was a time when the solution was “meta-level”, and “What was your question?” This was during the heyday of Logic Programming when it seemed that we were going to take over the world (when they woke up to it that is).

Meta-programming is extremely powerful, and it seemed that there was nothing that could not be solved using some kind of meta-level approach: compilers, debuggers, abstract interpretation, program transformation, utility programming; the list had no end.

Unfortunately there were, and are, some problems with meta-level programming. From a logic perspective a key problem was that you had to prove, again, the logical validity of the meta-level inferences that you made in your application. More pragmatically, there were issues with the ’standard’ way of reflecting from logical formulae to data structures in Prolog that caused logical and practical problems.

Like most Prolog-ers, I have been somewhat amused by the apparent enthusiasm for all things meta in the Java world. It has had a distinct been-there-done-that kind of feel about it.

Recently I came across one of the down-sides of the meta-fever. Wicket uses a lot of reflection to simplify programmers’ tasks. However, the down-side is that using a string to denote a method confuses most IDEs; making refactoring a tricky proposition.

June 29, 2007 - Posted by Francis McCabe | Service Oriented Architecture, computer architecture, logic programming | | 3 Comments

3 Comments »

This is not exactly a problem with Wicket. I see it as more of a general problem with Java’s reflection implementation. The best solution to this, as I have blogged in the past, would be to introduce property notations to Java that avert actual reflection for reflective references that are really (static) constants. We do this for classes with the notation Foo.class. So why not do it for methods and fields with Foo.value.field and Foo.value.method? It gets a little bit complex if you need to specify an overloaded method (maybe Foo.value(int, double).method), but the result would be static reflection that runs fast and refactors in your IDE.

Comment by jonathanlocke | June 29, 2007 | Reply
BTW, my view of uses of reflection in Wicket beyond simple properties like “person.name” is very dim. If you stuck to simple properties, there’s no reason you couldn’t say new PropertyModel(model, person.name.getter) (i just made up getter as an extension to refer to the method getName() in this case). Of course this doesn’t solve every problem in Wicket because of the use of compound property models. But if you wanted fully refactorable reflective code, you could simply not use that and it would all work.

Comment by jonathanlocke | June 29, 2007 | Reply
Wicket does not use a lot of reflection. Probably the least of all Java frameworks. The only construct that uses reflection is the PropertyModel, and it’s derivative CompoundPropertyModel, but this is a specific implementation. A convenient one, which is why it is used by so many people and in so many examples. But the equivalent of doing

new PropertyModel(person, “name”)

is

final person…
new IModel() {
public Object getObject() {
person.getName();
}

public void setObject(Object name) {
person.setName(name.toString());
}
}

Which imo is not that bad, just a bit verbose. And indeed, the advantage of the latter is that refactoring never breaks. In the project I’m working on, probably about 30% of the models are property models and the other 70% are variations of the later.

Comment by Eelco Hillenius | June 29, 2007 | Reply