First Class Java: further thoughts on dot notation for class metadata
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 username.property 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 @person.username.property or $person.username.property 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() {
bind(view.usernameComponent, @model.username.property);
...
}
...
}
where alternatively, the above might reference the java.reflection.Field literal as @view.usernameComponent.field.
This notation eg. @person.username.property actually represents a tuple of the instance plus the PropertyDescriptor, whereas @Person.username.property 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!?
- Login or register to post comments
- Printer-friendly version
- evanx's blog
- 1889 reads
by jwenting - 2008-06-16 22:19why 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.
by caroljmcdonald - 2008-06-16 07:59have you looked at ognl.org ?
by cowwoc - 2008-06-16 08:44Why 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.
by aberrant - 2008-06-16 07:51Please excuse me if I don't understand your syntax but prefixing the @ might cause problems when chaining calls. @getContext().getModel().username.property
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()@username.property
Another way to mix both meanings would be something like this:
@(getContext().getModel()).username.property
That seems like a more trouble then it's worth just to use the dot.
by evanx - 2008-06-16 11:51
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.
by evanx - 2008-06-17 03:47
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.