Skip to main content

First Class Java: Thoughts on a dot notation

Posted by evanx on April 5, 2008 at 5:03 AM PDT

So last week i started rambling about "First Class Java." Lemme continue while i wait for my clothes to dry on the line outside, whilst i prepare myself for a wedding this afternoon, which i love, especially the eating and drinking and chatting and laughing and dancing part of it.

So i was wondering what notation would be neat for first-class references to properties, methods and fields, for this so-called "First Class Java" exercise.

Since we have .class notation for Class eg. Person.class, my first thought was to have something similar eg. .property, .field, .method - waddayathink?!

For example, let's say our Person.class has a property username. Then we could refer to its PropertyDescriptor as Person.username.property.
We might also refer to it's Field and accessor Method as Person.username.field and Person.getUsername.method.

monkey1-200.png
Comrades here have been touting using a hash (which is quite neat) eg. Person#getUsername (for first-class method referencing), and we see things like Person->username for properties. The question is then what non-conflicting notation for fields!?

(As an amusing side bar on hash notation, many years ago i was hosting two decidedly non-techie friends from London, and roped them into a geeky Linux User Group year-end dinner party. They got thoroughly bored, their heads down with all this technobabble going around and over their heads. The only time i saw them whip their heads up was when they heard the word "hash." Disappointingly for them, not the type they could converse about, but rather further technospeak related to unix scripts, which caused a further shoulder-drop. Heh heh.)

Back to the beef. Besides the hash and -> notations, for closures we see a => notation being bandied about willy-nilly. Urrrrgh!

The problem is that firstly, i personally dislike with a revulsion that is impossible to put into words adequately, such double-dastardly punctuation symbols like C/C++'s hideous ->, and => is even worse! Having said that, i don't mind C/C++'s &, and of course we all love it's dot notation for referencing.

Given that we have too many first-class thingymajigs like properties, methods, fields, and given that Java's preference in general is words rather than punctuation, eg. extends rather than C++'s doubly-distastful colons, i say using words like .method is better, and inline with Java's existing "dot-word notation" for meta-majiggies ie. .class.

In general, less char's is not better. (Where by "char's" i mean "characters," as a case in point.) Java takes the approach of readability over brevity, eg. lastKnownWhereabouts over lstKnwnWhabs, and extends rather than colons. (Lemme not launch into a whole tirade about unixen /usr and /tmp, and the elitist-obscuritism to which i am philosophically and psychotically indisposed.)

Given the above, a related point on the subject of closures is, sure, introduce closures if it's gonna simplify and robustify our libraries, API's and programs. But let's continue Java's legacy of beautiful readability rather than introducing the dastardliness of C++'s duplicitious punctiliousness.

Enough semantic monkeying around from me - please restore some sense and sensibility to this posting with your affably obliging comments - thank you very much! :)

Comments

but person.username.property would be fine, if one didn't allow attribute "property" like "class" isn't allowed?

i understand that hash is in javadocs and not foreign, but i do think that would be like the tail wagging the dog, and i would have preferred dot to be used in javadocs in the first place! ;)

personally i'm put off the closure proposal by it's => which i think is ugly and would be better to have a keyword eg. closure !?

I agree with you i think .method or .property is much better than -> or # or some other special symbols shits. If Java 7 have things like # or -> in the language for property support for closures and etc I will switch to C# becouse in C# only the name is ugly not the language.

Take a look at at least one unilateral improvement to java. I think it would be cool if the IDE makers made this a reality before Sun did.

The problem with using Person.username.property for properties is that it only covers half the use cases - http://www.jroller.com/scolebourne/entry/java_7_properties_terminology

The bean-attached properties (and bean atached methods/fields) are just as important as the bean-independent ones, especially when working with frameworks. Coming up with different notations to achieve them both without using a new operator (#) is very hard.

I totally agree. I have already implemented the .field and .property as "abstract enum" in my kijaro branch, and I really like playing with it. Having them as enum is great:
  • iteration with .values()
  • find with .valueOf(String)
  • enum kind of switch
  • placeable in annotations.

The "asbtract enum" change is quite small for Java and proved very efficient. Hope more people will vote for it: 6570766
And again: Please no more "->" :(

freddy, i like that abstract enum!

stephen, i agree bean-attached properties is very important, eg. for beans binding. Having said that, a framework could have BeanProperty with two attributes, the property descriptor for the class/property, and bean instance.

i'm thinking that having something like Person.username.property is most important for tooling and refactoring rather than brevity per se?

Having said that, couldn't Person.username.property refer to static PropertyDescriptor, and person.username.property represent bean-attached property ie. PropertyDescriptor plus person bean instance reference eg. BeanProperty?

One problem with overloading the existing "." notation is that the code you are writing is already valid. It already means something. Someone somewhere might have code that has a Person class with a username public field that has a property field. Should that code break? I totally agree that readability is important. Personally I don't find the # to be a big deal, but I respect you opinion. If you want something more verbose what about this: Property p = Person:property:username; Method m = Person:method:getUserName(); Field f = Person:field:username; It works the same as the # notation but it describes what the desired target is.

As stephen says, there is a syntax clash
moreover, '#' is already used in javadoc comments, the closure proposal already use '#', so the of '#' to acess to a property object is not that alien

Rémi

aberrant, those colons do look nice and unobtrusive. I had thought about the issue you mention (eg. some existing class has an attribute .field) but while i don't think that's necessarily a showstopper, anyway this exercise is one of dreaming about an idealistic first-class java, without being overly concerned with implementation, backwards compatibility, et cetera :)

java tends to be quite "wordy" and not overly punctuated and certainly not abbreviated (eg. method names et al) - which i think is something that is beautiful about java ie. more naturally readable eg. "class Person extends Entity" which is how programmers might describe the code to each other - it's nice when you can read aloud the code word by word as if its natural english, without !@#$%^* ;)

Having said that, i reckon the language designers wanted to adopt as much the same as C/C++ as possible, and "extends" and "implements" were introduced because they opted for having interfaces and not multiple inheritance. Still i think it's nice to be wordy!

Limiting the punctuation to dot primarly as it is now, and making it more wordy if anything, for readability, eg. for closures et al... It's nice!?

i hear you mikael. One can introduce frameworks like beans binding, but programs may still not be refactorable (eg. safely renaming properties), and still require lotsa boilerplate (firing property change events in setters).

Still I do think that astetics are tremendously important, and other minutia like consistency, readability...

Seriously, which character that will be used is IMO not very interesting. It is easy to have an opinion about it though. We will get used to whatever is done anyway. What is important is how flexible and easy to use the properties are. And if you can remove boiler plate code with it or not.

You can't use person.username.property for the bean-attached property as person.username will mean the same as person.getUsername() does today. There is a syntax clash. The purpose of a separate symbol like # is to separate access to the meta elements from the standard elements of the program.

aberrant, they alread solved this when they introduced the assert keyword. Source code version is just an attibute in the javac task of an ant file. You have to wait until those (I guess about 5) libraries which use a non private member named property etc. are upgraded.