CFCs, Performance, CF9, 2009, and Reactor
Dutch Rapley
Adobe MAX SF happens next week. There will be, no doubt, several product announcements in regards to CF9.
I think there's going to be a major announcement from which Reactor will greatly benefit. As a result, I do believe we'll probably be looking to rewrite/refactor Reactor in 2009. Hear me out.
Think about this: the codename for CF9 is Centaur. Centaur is part man, part horse. He is a hybrid. CF9 will be a hybrid.
In CF9, we'll be able to write true classes in CFScript. We well see the implementation of access to the entire CF tag library in cfscript fashion. We will have import and new keywords. We will have implicit getters and setters.
We'll see something like the following:
public function get firstName():String
{
return this._firstName;
}
public function set firstName(firstName:String):void
{
this._firstName = firstName;
}
When using reactor, we'll no longer have to do
Employee.setFirstName("Bob")
Employee.getFirstName()
We'll see
Employee.firstName = "Bob"
Employee.firstName
But, implicit getters and setters won't be the reason we'll rewrite Reactor. The reason will be performance. It is no news flash to anyone here that object creation with CFCs is slow. For now, it's performance trade off we make in order to reap the benefits by using somthing like Reactor. (BTW, how noticeable is the performnace hit?)
Currently, there's some hubbub around using groovy with ColdFusion. With CF9, we'll see real scripting. We'll be able to write CFCs in pure script. We'll be able to write CFCs/classes that will exented already existing CF tags.
The point I'm making here is that cfscript will become ColdFusion's equivalent to groovy. Object creation will be blazinging fast b/c it'll become a 1st class citizen in CF. Also, think about the inclusion of hibernate. Is hibernate something you'd really want to implement with CF tags? No. Thus supporting my believe that CF will bring on full featured scripting.
There's also a vantage point here. Java programmers are moving towards Ruby/Rails and groovy b/c they are RAD platforms. Plenty of them turn their nose up at CF b/c it's tag based. CF9 will be the new RAD platform for Java developers.
When I say we'll rewrite Reactor, we won't change how it works, but what we will do is rewrite all the tag based CFCs as true objects in CFScript. While I do expect to see some performance increase in tag based CFCs, the real performance gains will be from script based objects.
What I do realize is that the "new" Reactor won't run on CF8. I do also predict an incredibly high adoption rate for CF9.
Discuss!
-Dutch
Doug Hughes
I love the enthusiasm, but are you not looking a little further down the road than perhaps is warranted? What I mean is, we really don't know what the final features of CF 9 will be so it's hard to plan for them. Secondly, I doubt that if Adobe makes CFCs in general "true" java objects that they would only do this for "script based" cfcs. I would expect this to be true for tags as well. And, in general, I've always despised CFC script. It seems like a lot of busy work for no real gain at the moment. It's nice to use the new features, but isn't required. That, and it's not reverse compatible to previous versions of CF.
That said, I'm not adverse to a forking of Reactor which is neither reverse compatable nor actually Reactor, but something different.
Doug Hughes, President
Alagad Inc.
dhu...@alagad.com
888 Alagad4 (x300)
Office: 919-550-0755
Fax: 888-248-7836
Tom Chiverton
> In CF9, we'll be able to write true classes in CFScript. We well see the
> implementation of access to the entire CF tag library in cfscript fashion.
> We will have import and new keywords. We will have implicit getters and
> setters.
> We'll see something like the following:
Maybe. I dunno what's public at this point out of that list.
If there was even a 'pre release' scheme that anyone could join.
> When using reactor, we'll no longer have to do
> Employee.setFirstName("Bob")
> Employee.getFirstName()
> We'll see
> Employee.firstName = "Bob"
> Employee.firstName
*If we decide to change the Reactor API*.
Your suggestion would break existing code, and require (a version of)
Reactor that is CF9 only.
> The reason will be performance. It is no news flash to anyone here that
If CF9 has script-only CFC, I doubt you'll see any performance
difference because it'll compile to the same Java byte code as a CFML
CFC.
> equivalent to groovy. Object creation will be blazinging fast b/c it'll
> become a 1st class citizen in CF. Also, think about the inclusion of
It is in CF8. And under non-buggy JVM, I understand the object
creation overhead is minimal though we're not busy enough to have to
try this.
> Ruby/Rails and groovy b/c they are RAD platforms. Plenty of them turn their
> nose up at CF b/c it's tag based. CF9 will be the new RAD platform for Java
> developers.
You'd have to ask the Railo folks, who are positioning themselves as
'the' RAD language for J2EE w/JBoss, which if any of those are true.
> When I say we'll rewrite Reactor, we won't change how it works, but what we
You just suggested an incompatable change in the API.
> will do is rewrite all the tag based CFCs as true objects in CFScript. While
> I do expect to see some performance increase in tag based CFCs, the real
> performance gains will be from script based objects.
As and when there is a CF9 to play on, of course we'll look at if
there is any benefit to whole-script CFC as opposed to CFML CFC.
We'll have to see. It'd have to be very dramatic to warant a 'rip and
replace' of CFML.
But I don't expect we want to make Reactor break peoples code (without
calling it v2), or make Reactor CF9 only.
> What I do realize is that the "new" Reactor won't run on CF8. I do also
> predict an incredibly high adoption rate for CF9.
Nah. It'll be slow and steady, same as 8 (7, for that matter) based on
how quickly people have (not) upgraded so far.
Other frameworks do have separate code paths for different run time (versions).
It's stuff we can look at post-public release of a CF9 run time, maybe.
For the mo., though, I think we have more important stuff to do
(despite my own forward looking post the other week).
--
Tom
Dutch Rapley
While I currently agree with Doug on the fact that cfscript is "useless" (and hardly ever use it myself), I do think a major overhaul is due. I do think that it is inevitable that cfscript will eventually be faster than using tags (for some things). I think the main reason behind this is the fact that there's some busy work going on when tags are converted to byte code, whereas cfsript will be more direct along the lines of groovy. I would expect groovy like performance with cfscript.
With a "new" cfscript, aside from the busy work of typing it, we'll be able to extend CF in new ways. Something like the following will be possible.
import coldfusion.utils.XML
public class CustomXmlClass extends XML
{
public function CustomXmlClass()
{
}
}
Ok, I'm getting back to work now, and will get back to working on Reactor documentation. Once again, I'm really looking forward to this.
-Dutch
Mark Drew
>
> public class CustomXmlClass extends XML
> {
> public function CustomXmlClass()
> {
> }
> }
>
Why would me need to do this?
if anything
CustomXMLClass extends XML {
CustomXmlClass:XML(){
}
private:CustomXMLClass:XML(){
}
}
otherwise we are just cooking with Java aren't we? Besides, neither of
the above is that clear. And where do classes come from? They dont
exist in CF as far as language is called, its a Component ;)
MD
--
Mark Drew
Adobe Community Expert
Blog: http://www.markdrew.co.uk/blog/
LinkedIn: http://www.linkedin.com/in/mdrew
Dutch Rapley
To answer "Why do we need this?"
That sounds an awfully lot like the question that was asked when CFMX came out with something called components.
Yes, I agree, it's Java-ish or ActionScript-ish, whatever you want to call it. Not that it's related to CF, but I've been doing a fair share of Flex lately. While I use the built in tags where I can and where it makes sense, I also do a fair share of exenting them and writing AS to accomplish what's not baked in.
If/when true scripting is released in CF, I'm not saying it should be used for *everything* but it will come in handy for somethings. It'll be all about being pragmattic and deciding what's best depending on context. Most CFers won't use it. Most never will. But it'll be there for those who have a need.
-Dtuch
Tom Chiverton
it's a rare one time operation from reactor's point of view, any real
or imagined script vs tag speed difference now or later is mostly
unimportant.
--
Tom
Doug Hughes
Anyhow, that goes for everyone. Pipe up with your opinions and don't be discouraged by naysayers.
Doug Hughes, President
Alagad Inc.
dhu...@alagad.com
888 Alagad4 (x300)
Office: 919-550-0755
Fax: 888-248-7836
Dutch Rapley
What features are in Centaur?
Although we have not publicly disclosed the entire feature set of Centaur, we have discussed several features at events. The following information has been disclosed about Centaur.
- Built-in Object Relational Mapping
- ColdFusion services exposed for Flex and AIR via Actionscript libraries
- CFC Enhancements
- Implicit Getters and Setters
- Explicit local scope
- CFSCRIPT Enhancements
- Full definition of components via script
- Closed gap between CFML and CFSCRIPT
- Language Enhancements
- New and Import Keywords
- CFFINALLY and CFCONTINUE
- onServerStart method
More features will be included in this list as we publicly announce them.
-Dutch
Dutch Rapley
http://dutchrapley.wordpress.com/