What you're suggesting is predicated on the above statement being true. But it's not, in most situations. Basically you're not using a CFC instance an object, you're using it as a bag-of-functions. That's not the intent. It's an entirely valid practice, but it's not the intent.
Thats a very arguable point Adam. Looking at all the 'bag-of-functions'
CFC listed on CFZONE, and the majority of them are not holding instance data. It depends largely on your application development; so to say one way or the other is wrong. One has to accept that CFC's are flexible enough to allow both situations and leave it that.
[Incidentally Micha] i am not talking about the overhead of compilation of the CFC; merely the extra housekeeping that goes on to actually create and manage that CFCs memory space. Post compilation stage.
A CFC is an object. How one uses that object is really up to the end developer. Many other languages have the notion of the caching of objects at a core level, free the developer from the management of it. (JSP has a number of tabligs and now the JCacheAPI going through the JCP).
So why shouldn't CF expose that same level of functionality to the developer?
---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
