Skip to main content

First Class Java: further thoughts on dot notation for class metadata

Posted by evanx on June 13, 2008 at 7:42 AM PDT

Who knows why i have a dislike for symbols like ->, => and even := ?! It's pathological, i know that, and i have an obsessive-compulsive (dis)order when it comes to code, and so be it.

So in the previous posting in this series of reports on my pointless coffee shop doodlings, i suggested the likes of to refer to a PropertyDescriptor eg. for the purpose of toolable bindings, where by "toolable" i mean auto-completable, machine-verifiable and safely refactorable, using an IDE. If nothing else, this conforms to the current notation vis-a-vis .class eg. Person.class.

Now i'm thinking or $ don't look too bad, although many others suggest person#username of course, citing JavaDoc's notations, which i say is like the tail wagging the dog, but so be it.

So what's the big idea? Actually there is no big idea - only a small incremental idea, which is... Let's enable code that is fully toolable, refactorable, et cetera. Which means no references to properties in string literals eg. bind("username", ...). And code that still looks as nice and natural as possible, which to me means using the dot notation as far as possible eg. @company.contactPerson.displayName.

Let's imagine some code...

public class LoginController extends BasicController {
    LoginView view = new LoginView();
    LoginModel model = new LoginModel();

    public LoginController() {

where alternatively, the above might reference the java.reflection.Field literal as @view.usernameComponent.field.

This notation eg. actually represents a tuple of the instance plus the PropertyDescriptor, whereas might literally be the PropertyDescriptor, from which we can get the declaring class ie. Person.class eg. via getReadMethod().getDeclaringClass().
Method's are a bit troublesome 'cos of overloading, in which case one might need to refer to their parameter signature to differentiate them eg. @view.load(Weapon, Ammo).method
which i don't like the look of, but so be it.

Talking about methods, what about "first class methods", anonymous methods, closures or what-ever. Because people find anonymous classes a bit tedious, and many people are aggrieved that Java hasn't got closures like all other popular languages!?

My feeling at this minute is that if, like generics, closures can't be implemented simply, then they shouldn't be implemented at all, if the code examples look almost as unreadable as line noise!?


why can't you guys just leave the language alone instead of constantly trying to make it a mess by introducing new "features"? Java works, any changes like this are solely for the sake of changing things, for the purpose of getting your name in print.

have you looked at ?

Why do you need a special symbol at all? You could figure out whether a user is referring to a field or its value depending on the expected return-type. For example, if a method parameter is expecting a Field, then "myClass.myField" should return a Field instead of its value. This is probably more difficult to do from a technical point of view, but it is likely more intuitive to most people.

Please excuse me if I don't understand your syntax but prefixing the @ might cause problems when chaining calls. @getContext().getModel()

So what does the dot mean and where?

Infixing the notation lets you combine both concepts. Although you don't get to use the dot notation. getContext().getModel()

Another way to mix both meanings would be something like this:


That seems like a more trouble then it's worth just to use the dot.

aberrant, you're right. but I do like the "@" symbol indicating up front that we are talking about meta data rather than ordinary data. And i don't otherwise like mixing symbols, altho clearly that is more correct. I guess the "@" is superflouous given the ".property" at the end.

carol, expressions are great, EL et al, but the problem remains that they make code refactoring unsafe (without having tests). I wish for first-class meta data referencing to be extended beyond .class, to include .method, .field and mostly, .property.

jwentig - because of the reasons given - toolability et al for beans binding et al. That includes safe refactoring of beans eg. property names. Besides which i'm not changing the language, just trying to get my name into print ;)

but in general i agree with you that complexity shouldn't increase eg. messy looking generics and closures.