The Dopefly Tech Blog

<< The Dopefly Tech Blog Main page

Should CFML have first class properties?

posted under category: ColdFusion on December 3, 2009 at 1:00 am by MrNate

C# was the first mainstream programming language, to my knowledge, that had full language support for properties, phasing out getters and setters (accessors and mutators). The idea is simple. Here is a property:

public String Name;

This gives your object a public property that can be read and written. The process is similar in Java and ColdFusion, but when the time comes to add functionality to Name, such as calculate the value on the fly, or invalidate a cache when the value changes like I do in Pagination.cfc, you have to graduate this into a getter and setter. In C#, you just have to change the property, keeping your object's interface safe:

private String _Name;
public String Name {
get {
// some code
return _Name;
set {
// some code
_Name = value;

Properties inherit simplicity when compared to the standard getter and setter. They give you less typing and fewer interface changes.

It can actually go deeper than that, with property change event listeners and more.

In the Java world, this properties debate has raged for years, and there are opponents and proponents, both shouting angry words at the other side (they call it the JCP). I think it will never happen, Java is a mountain: basically immobile, without an act of God. CFML is a rocket, in comparison. Allaire / Macromedia / Adobe have pushed CFML hard, keeping it current. Much more so with the latest release and the CFML Scripting enhancements.

Adobe ColdFusion 9, which came out a few months ago, blessed us with near magical getter and setter generation, but I wonder if that is not enough. With this feature in place, is it now too late to move the language toward properties? I suppose this becomes a question for (or your potential answers for) the CFML Advisory Committee: how could it be implemented in CFML, the ColdFusion way?

Too old to comment!
On Dec 3, 2009 at 1:00 AM Andrew Scott (andrews, visiting us from said:
Your blog post is around the wrong way.

Properties have been around for alsmot 30 years, .Net introduced Setters / Getters to get people away from changing the properties and to provide code for validation of the data going into the property.

ColdFusion has setters / getters for that exact same reason, as well as to encapsulate the property as well.

ColdFuison already allows for properties to be touched, edited and such. But this provides no encapsulation on the data.

Until ColdFusion moves away from a typless langauge (which will never happen), then getters and setters are here to stay.

Also if anyone is arguing in the Java world then they are not seeing that you can add extra code for further validation ond processing if it is required.

On Dec 3, 2009 at 1:00 AM Nathan Strutz ( said:

Yeah I probably did get the subject somewhat backwards. I concede that I'm not an expert in language design.

The validation argument is a good one, however it is much more relevant for pure Java, where accessors/mutators and beans actually mean something, and where everyone follows a convention. In CFML, it's not so.

I'm proposing properties as a means to (1) type less and (2) keep component APIs from breaking.

Typing less, meaning person.setName("Nathan");person.getName();
versus = nathan;;

Keep component APIs from breaking, meaning when you start with a simple"Nathan", and you need to turn that into a more proper function, you currently need to make a mutator, setName(), then hunt down and change all code that does it the old way. Believe me, that's a lot of work.

Validation is interesting, but it's not the end-all. Properties make a language simpler.

This argument comes up every 3rd (or so) episide of the Java Posse podcast, so I know the Java world is talking about it. They are getting language envy, which is why many of the leading Java-heads are looking at better languages (Groovy & Scala, etc.).

As for C#, run a google search and see what it is like in real code: You may like what you see.

On Dec 4, 2009 at 1:00 AM Andrew Scott (andrews who dances with said:
Hmm, let me see I think it boils down to your choice and preference. I understand what you are saying, however as I stated you are going to have to get CFML to move away from being typeless for this to work.

It is already possible with the this scope as you mentioned if you want to make them public.

Validation is not the be all and end all, but in CFML it means eveything when it comes to making sure that the variable is of the type it needs to be. Otherwise you are going to be writing extra code all over the place to check that it is a struct or it is a string etc. And trust me that is a lot more code than you might think about.

I do not need to do a google search, I have been programming in the .Net side of things ever since it was released and my preference of that side is C# and alwasy will be as I think it is a very nice and clean language.

But its not all about just validation either, for example I might have a component or as I prefer a userService that can pass in a string as a password to the setter, I can then encrypt that string into the storage before it hits the DTO and gets persisted to the database.

But validation is the key point, because the database might only allow upto 16 characters for that password. And how to a check the constraints of that string if I am only ever using the properties way of doing it.

People have been debating the pros / cons of both methods for over 10 years and I dare so that they will be doing so in the next 100 years as well.

My logic is that if you are blind sided and argue against getters / setters then you aren't thinking logically in the first place, because if you were then you would see that from a refactoring point of view, getters and setters are far easier to refactor than by using the property alone.

On Feb 20, 2010 at 1:00 AM Mike Kelp (mike.kelp, by way of said:
ActionScript also does really well in both implicit properties and static / dynamic functionality with implications for CF.

AS Example:
/* Simple Public Property */
public var firstName:String = "";

/* Property using custom getter-setter */
public function get firstName():String {
// logic

public function set firstName(value:String) {
// logic

The ":" syntax allows is a great way optionally type variables.
// Static
var myString:String = "";
// Dynamic
var myVariable = "Whatever I want"

I bring up optional strong typing because I think this syntax is a very elegant way to handle both concepts and offers language / compiler simplicity while the developer gets exactly what they want with a clean syntax. Ask yourself how often you write code that not only changes the type of a variable from when it was original set, but depends on that ability to do so? Dynamic typing is a wonderful tool, but can often allow us to write bugs into code or write confusing code when it is not used with respect to the architectural requirements.

In CF, I imagine being able to use cfproperty like so:
<!--- Public Property --->
<cfproperty name="firstName" type="String" />

<!--- Implicit getter setter property definition for dynamically typed version --->
<cfproperty name="firstName" getter="myGetterFunctionName" setter="mySetterFunctionName" />

Just throwing this out there as this is something I've thought about a lot over a few years. This would allow for complete structure style notation on our properties and complete control of what they do for validation, change tracking, etc. On top of that, the way the underlying compiler treats it is clear as possible, so it could be optimized for typing / concrete java code without worry of damaging the functionality (potentially even using it in "bean" cfc objects for cf9, etc.

Sorry for the long comment, but I'm disturbingly motivated by this subject haha.


On May 26, 2010 at 1:00 AM Adam Cameron (adam_junk at the endearing said:
I dunno that they're phasing out getters and setters, it's more like they just use implicit getters and setters (as per your example). But that's splitting hairs slightly.

I don't understand where Andrew is coming from (hi Andrew, btw) in that because CF is typeless it cannot have implicit getters and setters. I don't see the connect. Anyway, isn't it true that properties on CFCs are indeed typeful these days? I mean one can chuck a string at a setter and CF will handle the casting to some other type if it can (say to an int or a date), but if you try to stick a string into a property that's supposed to take an object: CF will raise an exception.

I suppose one disconnect going on here is that perhaps Andrew is thinking of the fact that one can just (from the calling code) go:

myObj.anythingYouLike = "some value";

And CF will stick a variable in the public scope of the CFC instance. However I should think if one was to go:

myObj.somePredefinedPropertyName = "some value";

Then it should not be too hard for CF to "see" this and call an implicit setter if there is one.

Note: some people (including the CF9 documentation still, I think) are erroneously referring to those auto-generated get/set methods as "implicit getters/setters". Those are not implicit getters & setters. What you describe in your blog post are implicit getters and setters, and that is what I am meaning when I use the term here.

FWIW, I heartily agree that having implicit getters/setters would be quite slick. It's a feature I like in C# (along with everything else in C# I've come across so far, but I'm a newbie with it).


On May 26, 2010 at 1:00 AM Adam Cameron (adam_junk, by way of said:
Your email "validation" claims that is not a valid email address. Yes it is.

Too old to comment!