I would only expect that to work if foo() took no arguments and didn't return a value. "include" works like most folks in this thread seem to expect in C / C++ because those languages have a preprocessor that is a simple text substitution engine. When you compile a C / C++ program, the source code is preprocessed first - all includes and macros are processed - and then the resulting source code is compiled. This sort of naive source code processing is powerful but not considered a very good model by a lot of language advocates (well, advocates for languages other than C / C++!).That is because you come from a compiler world. Pure runtime languages don't have these issues including CFML until recently.
In almost all other modern computer languages, there is no preprocessor and files are compiled on a per-file basis which means that each file must be syntactically correct in its own right. Since <cfargument> and <cfreturn> only make sense when they are inside a <cffunction> tag, it seems reasonable to me that you can do this:It is certainly syntactically valid; it just requires that the function's meta data isn't known until runtime.
<cffunction name="foo"> <cfargument name="bar"> <cfinclude template="foo.cfm"> <cfreturn 42 /> </cffunction>
but you can't have an 'include' file that contains this:
<cfargument name="bar"> <cfreturn 42 />
because that is not syntactically valid. When you think about how CF has always treated files - that they can be <cfinclude>'d or *called* as custom tags - then there ought to be at least a suspicion that <cfinclude> doesn't behave quite like cut'n'paste (despite what the docs say).
And that brings us to the docs. The obvious way to explain <cfinclude> is to say it's like cut'n'paste because most people understand that - especially folks with little or no programming background. Now, as several folks here have complained (and rightly so), that explanation totally breaks down when <cfinclude> is used in the context of a CFC. That's not because CFCs are inherently broken but simply because of the way that <cfinclude> has always really worked, i.e., it ain't cut'n'paste.Besides the fact that you can't open and close tags in different files, cfincludes really do act like cut'n'paste. For example, try including a binary file.
CFMX6.1 fixed them. You may argue that it didn't fix them enough - certainly CFCs are not (and probably never will be) clones of Java's classes. There's a lot of reasons for that and I know that not all of you agree with those reasons. But, the basic things that were intended to work (but didn't in CFMX6.0) did get fixed.Let's not go down the road of CFCs vs. Java classes. CFMX 6.1 did not total fix the include issue because as this thread clearly demonstrates the expected behavior is still not the behavior.
Technically, the behavior does not differ based on context - a <cfinclude>'d file is, after all, just another 'page' object that is invoked from the calling 'page' object. Since scope lookup is dynamic, 'variables' and 'arguments' bind to whatever the calling scope has which makes it appear to be context-dependent.That is just silly. It doesn't matter that there isn't logic in the cfinclude tag implementation itself for different contexts. What matters is that when cfinclude interacts with certain other tags it has different behavior.
I don't think CF is a perfect language by any means and I've been critical of several of its shortcomings but I've also come from a CFMX-only world so I'm not trying to see CFMX through CF5 glasses (in fact, if anything, I tend to see CF5 through CFMX glasses!). For me, CF has always had components and has always compiled each file (and each function) to a separate (bytecode) class.I certainly understand where you are coming from, but you are not the average CFML developer or even a good sampling for that matter. The expectation that CFML developers should understand the difference between compiletime and runtime issues is wrong. There is a reason why CFML was many people's first programming language; its learning curve. I would argue that any language that makes use of a compiler is inherently harder to learn for those with no programming background. Thus, the changing expectation has the dual effect of adding more bugs in CFML applications and a steeper learning curve for people just learning the language.
-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]
