Other Approaches to Getters and Setters

I tend to like Joe's approach. It takes an existing language feature (cfproperty), creating a ColdFusion appropriate API for beans and making it clear what the properties are and which are gettable and settable.

His approach just sets access as private or public rather than providing the slightly more granular control of making gettable and settable separate annotations. In a real world implementation I'd probably have the two properties as I can think of cases where you might want to have Final properties that can't be edited (this assumes some kind of separate load method or setting of state as part of the init() method that used what would be effectively private setters for initializing the Final properties).

It's also dependent on onMissingMethod() so it's CF8 only. The only practical implementation I can think of for cf7 would either involve generic get() and set() methods which read from the cfproperty annotations in deciding whether to allow the properties to be gettable and settable (I played with code working just that way using cfproperty a little time back) or using some code generation and mixins to mix in getters and setters at runtime.

There is also the edge case that by not prefacing the variable names with "get" for the getters that you could run into conflicts if you ever had an object with a property that had a name identical to that of an actual method (I can't think of a good design that would have that problem - but I haven't thought about it very much so I might just preface the getter method names with "get" to be safe - it also makes the oMM() parsing easier if you have other classes of missing methods as you can "if left(name, 3) eq "get" . . .).

I actually quite like Joe's approach and think there would be good use cases for that kind of implementation.

I'd use it myself, but I don't actually have class files for most of my classes, so I can't rely on their being a physical file with cfproperty tags in. But I'll get into that story/argument/approach/design decision another day!

Of course, all of these approaches have downsides. If you're relying on some kind of automated JavaDocs style documentation generator it would have to be cfproperty aware otherwise it wouldn't actually document the API, and while cfproperties aren't just a "magic string", they aren't methods, so they won't show up in a component explorer and if some kind of code completion solution for methods was ever implemented for CF (a very non-trivial project for a dynamic language), it would have to be written to consider cfproperty as part of the API. Everything is a trade off, but having worked with code both with "dumb getters" and without, I believe there are definitely use cases where the more concise expression would be worth the relatively minor loss of tooling support.