It is implemented this way so you can <cfinclude> a function library into a <cfcomponent> tag and access the UDFs in it - without polluting the methods in your CFC. If I recall correctly, you can also <cfinclude> a function library into a <cffunction> tag - which makes the UDFs available just inside that method.Interesting... while that seemly makes sense it doesn't really fit with the semantics of CFML. Prior to CFCs, you could use a cfinclude anywhere you felt like and the results would be virtually the same as cutting and pasting the code. The example mentioned in this thread isn't the only place that breaks those semantics in CFCs. For example, it isn't possible to use an cfinclude for the entire function body i.e. you can't cfinclude cfarguments and cfreturn. What is the reason there? I suspect the culprit in both cases is actually the compiler approach. It kind of sucks CFML developers now have to concern them selves with compiler related behavior now when the language was always interpreted at runtime; cfimport being a prime example.
-Matt
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
