ColdFusion 9 Implicit getters / setters change

If you downloaded the new version of ColdFusion you may have found that some things have changed from the public beta you were using. The first that you need to know about is implicit getters and setters are not created by default. If you create a component with some properties it does not automtically create them for you. To accomplish this you just need to add an attribute to your component.

This of course is not the case if you are using ORM. If you set the component to persistent it will know that you need getters and setters created for you properties.

Categories: Uncategorized

About The Author

My name is Dan Vega and I am a Software Developer based out of Cleveland OH. I love to play with new technologies and write about my experiences here. When I am not busy being a full time geek I love to lift heavy weights and hang out with friends and family. If you have any questions please don't hesitate to contact me.

Follow me on:
  • Mark Mandel

    @Brad – every single one of my service layer component, and data layer components have implicit getter/setters AND use onMissingMethod, so having what you would suggest would break my code.

    Having weird arbitrary rules for when implicit getter/setters exist only cause to confuse the issue further. A simple flag for being able to turn it off makes life easy for everyone, as then it is very clear exactly what is going on.

    @Dan good post!

  • Ben Nadel


    Ahh, ok that would make sense then.

  • John Whish

    I seem to remember hearing that one reason was to improve performance as CF doesn’t need to read the component properties and create implicit getters and setters if it doesn’t need any.

  • Dan Vega

    Thanks Rupesh!

  • Ben Nadel

    I am not sure how it would break anything. For backwards compatibility, your defined methods would win (as they always did).

    … actually, what probably would break is using OnMissingMethod() to auto-wire Get/Set property values… so in that case, I guess it would be bad :)

  • Ben Nadel

    Explicitly defined Getters / Setters will override the ones CF would synthesize (according to Rupesh and Mark Mandel).

  • John Whish

    @Ben, I might have made that up (I can’t find anything to back up that claim!), but it does make sense, particularly if you’re using cfproperty for webservices etc.

  • Brad Wood

    @Mark: My suggestion accounted for your situation. Your services and DAOs would be the "exception" in that they implemented an onMissingMethod AND required implicit getters and setters and therefore you would be forced to explicitly state your desire for CF to create them.
    I can understand us wanting the logic to be consistent and simple, though I would call the terms "weird" and "arbitrary" a bit of a stretch.
    I was building off Tony’s desire that implicit gets and sets should be a core part of the language as often as possible and not have to be enabled to encourage their adoption. Therefore, the most appropriate solution would seem to be finding the 80/20 ratio. Which default would be the most common and which one would require more people to retrofit their code?
    ColdFusion 9 has still broken parts of some frameworks with its new functions so obviously Adobe weighed the trade off of 100% backwards compatibility with what made sense and would affect the smallest amount of people.

    Back to the discussion of what the default value should have been for implicit getters and setters; I personally rarely use onMissingMethod so I would have to make no changes at all. However the 2 of us are in no way a representation of the CF programming community as a whole. Honestly I don’t even know if Adobe themselves has statistics of which default would have affected the greater percentage of people without having access to every CF codebase. It seems they went with the safest method (which is understandable), but it by no means is the method guaranteed require the smallest amount of refactoring upon release.

  • Dan Vega

    good point..If anyone knows why the change was made please let me know.

  • Dan Vega

    Well that makes perfect sense why they would do that then. If they did not do it this way it could potentially break your component.

  • Ben Nadel

    If full name is computed, it seems like something that would only have a getter, not a setter? And, if you had an explicit getFullName(), that would work. Actually, not sure you would even need / want a property called "fullname"?

    I am OK with the accessors="true" as well; just seemed like an arbitrary change.

  • Brad Wood

    Just a thought Rupesh, but what if CF9 only created the implicit getters and setters if onMissingMethod was not defined for the component. It seems logical that a component using onMissing method would have a high chance of not want implicit gets/sets, and for the exceptions to that rule there would always be the existing cfcomponent attribute to override. That way implicit gets/sets could have stayed the default behavior for most components while still maintaining backwards compatibility with all the architectures using onMissingMethod.

  • Tony Nelson

    Well that’s disappointing. You’d think they would want implicit getters and setters to be a core part of the language rather than something that needed to be enabled…

  • Rupesh Kumar

    Ben guessed it right. We had to back it off because it broke Model Glue and couple of other applications that were depending on "OnMissingMethod". These applications had their own way of handling dynamic getters/setters and because of our change, we started intercepting it and the application methods were no longer getting called.

  • Dan Vega

    property firstname
    property lastname
    property fullname

    If you have a setFullName() that builds the first name from the first + last the implicit setFullName() would not accomplish the same thing.

    First thing that I thought of but I am sure other scenarios would be screwy. I don’t mind the accessors=true.

  • Ben Nadel

    I think the conflict with OnMissingMethod() would be the biggest worry – how would CF know which "missing method" function to you use – yours or theirs?

  • Dan Vega

    I would think for backwards compatibility. Imagine if you have a component that has properties in and you already have getters and setters written. I think there would be some issues there.

  • Ben Nadel

    I wonder why they changed this.

  • Matthew Lesko

    Little off topic, but is there a list anywhere of changes between 9 beta and release?

  • Jim Planter

    What I can’t figure out is how to set the component property value from within an explicit setter.

    Say I have accessors="true" set and my component has an explicit setter function defined for firstName.

    Is there no way from within the explicit setter to change the value of the property that ColdFusion maintains through the implicit setters?

    <cfdump var="#person#" /> shows the firstName property value but I can not find a way to manipulate it without calling an implicit setter.

    I’ve tried:

    * Returning the value to set to firstName

    Anyone know how to do this?

  • Dan Vega

    @Jim – I will write something up on this later today but you were really close. Every property is stored in the variables scope. If you want to create your own setter you will need to tell the property not to generate a setter method and that you are going to provide your own. I have a user who has a password property and when the string is passed in I want to hash it. This is what my user object looks like.

    * @accessors true
    component {

    property firstname;
    property lastname;
    property email;

    * @setter false
    property password;

    public User function init(){
    return this;

    public void function setPassword(String password){
    variables.password = hash(arguments.password);


  • Jim Planter

    Figured it out, it’s:

    * variables.firstName

    The collision of property and functions names in the variables scope gets a little funky. A function of the same name can only be accessed through "this", so the access has to be public.

  • Jim Planter

    @Dan – Thanks for the response. You beat me to it :)

    Certainly isn’t very intuitive.

    Man I wish the implicit setters would return "this" rather than void, so we could do method chaining: person.setFirstName("Jim").setLastName("Planter");

    I never got why they would engineer it this way.

    Also, the core functions that return boolean on success rather than the object being acted on really feels like a waste too. (i.e. structAppend() ). Ah well I’m getting off topic.