CF9 Feature Wish: Properties, please!
A long time ago, I did C# development. It was brief. I liked the language, but couldn't stand the project. The only good code that came out of it was Model-Glue and the the Alagad Image Component: Doug and I both had a lot of spare time during a 3-hour sync/build process that had to be performed manually.
That aside, one thing I loved about C# were its notion of "property" functions. Instead of writing getFirstname() and setFirstname() functions to hide the "firstname" property, you could simply declare a public firstname property. If you needed to implement data hiding, you could simply change "firstname" to a private mFirstname property and expose the public "firstname" by adding a getter and setter function:
public String firstname {
get {
return mFirstname
}
set {
mFirstname = value;
}
}
ActionScript 3 has similar features. When I model a class, I typically start with all-public properties, shifting to getter/setter functions wrapping a private variable as needed:
public function get firstname():String
{
return _firstname;
}
public function set firstname(value:String):void
{
_firstname = value;
}
Would it be that hard for ColdFusion to do the same? I'm tired of writing getter and setter functions (and writing and maintaining tools that do it for me). Other automagic solutions, such as onMissingMethod and mixins, result in what I call a "squishy" API: you don't know its form until runtime. Hard to document!
Here's something I'd love to see in ColdFusion 9:
...works exactly like now. It declares a property, but doesn't set it, just like "public var firstname:String". Developers work directly with instance.firstname.
When we need to "hide" data and have getter/setter logic applied, we can expand our property:
<cfsetter>
<cfset variables._firstname = value />
</cfsetter>
<cfgetter>
<cfreturn variables._firstname />
</cfgetter>
</cfproperty>
The <cfsetter> tag is basically a <cffunction> tag invoked when a developer performs an assignment to firstname, receiving a single argument named "value." When the firstname property is accessed, the <cfgetter> function is invoked.
It'd require changes to the "under the hood" mechanics of accessing public-facing members of CFC instances, but I think it'd be worth it.
I've sent along a feature request to Adobe asking for this. If you'd like to do the same, visit the feature request form. If you'd like to do it quickly, without typing your own feature request in, simply visit the form, change "This is a:" to "Feature Request," and paste the following text into the text area describing this feature:
private _firstname:String;
public function get firstname():String { return _firstname; }
public function set firstname(value:String):void { _firstname = value; }
Would it be that hard for ColdFusion to do the same? I'm tired of writing getter and setter functions (and writing and maintaining tools that do it for me). Other automagic solutions, such as onMissingMethod and mixins, result in what I call a "squishy" API: you don't know its form until runtime. Hard to document!
Here's something I'd love to see in ColdFusion 9:
...works exactly like now. It declares a property, but doesn't set it, just like "public var firstname:String". Developers work directly with instance.firstname.
When we need to "hide" data and have getter/setter logic applied, we can expand our property:
The <cfsetter> tag is basically a <cffunction> tag invoked when a developer performs an assignment to firstname, receiving a single argument named "value." When the firstname property is accessed, the <cfgetter> function is invoked.


I wouldn't put it on the top of my list of feature requests (which I am, by the way, beginning to formulate) but it'd definitely be on there. I'd prefer to see an implementation that doesn't require as much typing as the AS implementation.
Besides, from a functional perspective, this stands to be something that really slows down execution.
When will the CF community quit comparing ColdFusion (which is squishy by nature!) to C#, Java, AS2/3, etc., and start comparing it to SmallTalk and other loose-typed languages with rich runtime capabilities?
Quit trying to turn my favorite language into something bloated and yucky! ;)
PS - This subject was done to death... ripped apart and discussed ad-nauseum... a few months ago. The upshot? The amount of special processing required to make this work from any of several approaches would be both incredibly non-performant and a whole new special case for dealing with CFCs.
AFAIK, it ain't gonna happen. Frankly I hope it doesn't... this is the domain of code generators and Eclipse snippets, and soft-typed runtime languages in general.
I'm soooo not with you on this one. :D
Glad I checked with you over IM before replying to make sure you weren't meaning to be rude.
All: this isn't a flame war, it's just Jared picking on me in a Jared-like manner.
>This subject was done to death... ripped apart
>and discussed ad-nauseum... a few months ago
I've been busy. Sorry I missed it. Apparently the discussion was on Adobe's prerelease site, which I'm terrible at reading. Mind posting a summary?
> quit comparing ColdFusion (which is squishy by
> nature!) to C#, Java, AS2/3
I don't compare it to any other languages. I've been anti-interface-tag for a long, long time ;) (See "Get over it: CF isn't Java", May 16, 2005: http://www.firemoss.com/blog/index.cfm?mode=entry&...). It's funny to read Sean and others argue for interfaces in the comments. :)
As far as this enhancing the language, I think it would. I've seen a lot of people confused by <cfproperty> and then getters/settings, looking at the amount of code to model basic objects, and they go goggle-eyed. Isn't a large part of ColdFusion about making the powerful simple, something implicit properties do?
OK, seriously, sorry that previous comment was flame-ish... sometimes my thoughts get too literally translated to comments and posts (actually... more than sometimes). In thinking about this, the previous discussion was in a private venue that I can't really get into much... the upshot was that the demand for this feature was from a few very vocal, very technical people and it was distracting the rest of the group from the actual focus of the conversation at hand.
Adobe basically said that since there was demand for the feature from about 5% of the CF userbase, the effort involved and the special cases that it would introduce into the CFC model weren't worth it. Right now the basis for CFCs is pretty straightforward and in keeping with the basic nature of CF... structs, UDFs and scopes. Building in this sort of virtual code-generator sort of thing was (at the time) sort of outside the "right way" for ColdFusion.
Thinking about it now, with things like onMissingMethod(), maybe it's time to revisit the idea. Truth be told, it seems like a better use of cfproperty (though perhaps that was part of the reason it was a no-go from Adobe, since cfproperty is already pretty specifically purposed).
That's about all I can remember... seriously, though, as much as I think it's a good idea to discuss it, I'm not sure Adobe _can_ implement this because of how cfproperty works now. I know your syntax was proposed at the time, from several different sources, almost verbatim.
Just a thought ;)
If you are basing the dynamic get/set values of <cfproperty> declarations inside your CFCs, you *do* get the documentation, as your <cfproperty> now has semantic meaning, and can be documented against.
What's this do to unit testing? Will it still work? I honestly feel a bit bashful about asking a question like that since it seems like I should know, but it's not something I've ever done... bad bad me!
I also thought I'd point out that your statement that "from a functional perspective this stands to be something that really slows down execution" is inaccurate. The CF Server is in very simple terms a 'big compiler' (compiling CFML and CFScript into Java Bytecode) - there's no reason why telling the server to create getters/setters for you would do anything to performance aside from adding a few milliseconds to compile time - which is insignificant.
Also note that though I'm not sure how much Smalltalk experience you have (I don't have much) - implicit getters and setters (the same functionality we're talking about in this post) is a feature available in LISP - the most 'rich runtime' 'soft-typed runtime language' etc. (not fitting any description you gave of the languages you stated CF should not be compared to).
In the same spirit of your post - not a flame - just some commentary.
Please read the whole comment tree before you respond to a particular comment... people's perspectives can change as a comment tree unfolds.
Simon referred to this as "implicit" creation of getter and setters. But, unless I misunderstand something it still seems like I have to explicitly write the get and set code
I've always viewed property the same as Instance Variable. Do you think that is an incorrect, or incomplete understanding?
In VB.NET I can create properties with a qualifier other than public. I would expect that C# offers the same functionality. In AS3, instance variables can act the same way.
I'm not sure about Java, though.
die besonders günstigen Angebote für HP Business- Drucker. http://hondadealers.bestquestgroup.net
3 Schiffstypen | 3 Märkte | 3 Charterkonzepte – 218% Ausschüttung erwartet – Jetzt investieren!
Mehr Informationen » http://honda.bestquestgroup.net
Im vergangenen Jahr hatte Alfa Romeo dazu aufgerufen, einen passenden
Namen für das künftige Einstiegsmodell der Marke unterhalb des... http://infiniti.bestquestgroup.net
Gleich nach seinem ersten F1-Rennen bekam Heikki Kovalainen den Zorn http://hondabest.bestquestgroup.net
des Flavio Briatore zu spüren. Jetzt sieht er sich gereifter. http://acura.thequestusa.net