ColdFusion 9 Implicit getters / setters change

10/06/2009 | ColdFusion | 23 Comments

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. <cfcomponent accessors="true"> <cfproperty name="firstname"> <cfproperty name="lastname"> </cfcomponent> 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. <cfcomponent persistent="true"> <cfproperty name="firstname"> <cfproperty name="lastname"> </cfcomponent>

This entry was posted on October 6, 2009 at 10:41 AM and has received 6297 views. Comments 23 | Print this entry.

TweetBacks

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)

[Add Comment] [Subscribe to Comments]

#1 by Ben Nadel on 10/6/09 - 9:53 AM

I wonder why they changed this.
#2 by Dan Vega on 10/6/09 - 9:55 AM

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.
#3 by Ben Nadel on 10/6/09 - 9:58 AM

Explicitly defined Getters / Setters will override the ones CF would synthesize (according to Rupesh and Mark Mandel).
#4 by Dan Vega on 10/6/09 - 10:00 AM

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.
#5 by Ben Nadel on 10/6/09 - 10:04 AM

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 :)
#6 by Dan Vega on 10/6/09 - 10:07 AM

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.
#7 by Ben Nadel on 10/6/09 - 10:13 AM

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.
#8 by Dan Vega on 10/6/09 - 10:15 AM

good point..If anyone knows why the change was made please let me know.
#9 by Ben Nadel on 10/6/09 - 10:19 AM

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?
#10 by John Whish on 10/6/09 - 10:22 AM

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.
#11 by Ben Nadel on 10/6/09 - 10:23 AM

@John,

Ahh, ok that would make sense then.
#12 by John Whish on 10/6/09 - 10:31 AM

@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.
#13 by Tony Nelson on 10/6/09 - 10:38 AM

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...
#14 by Rupesh Kumar on 10/6/09 - 11:13 AM

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.
#15 by Brad Wood on 10/6/09 - 12:10 PM

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.
#16 by Dan Vega on 10/6/09 - 12:21 PM

Thanks Rupesh!
#17 by Mark Mandel on 10/6/09 - 5:05 PM

@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!
#18 by Brad Wood on 10/6/09 - 6:14 PM

@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.
#19 by Matthew Lesko on 10/7/09 - 12:36 PM

Little off topic, but is there a list anywhere of changes between 9 beta and release?
#20 by Jim Planter on 12/17/09 - 9:07 AM

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:

* variables.properties.firstName
* this.properties.firstName
* Returning the value to set to firstName

Anyone know how to do this?
#21 by Dan Vega on 12/17/09 - 9:50 AM

@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);
   }

}
#22 by Jim Planter on 12/17/09 - 10:06 AM

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.
#23 by Jim Planter on 12/17/09 - 10:17 AM

@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.