My opinion on this is still that, at the very least, since this is a change to previous expectations AND counter to how the functionality is described in the current docs.
CFCs have very poor documentation, period. If you're going to change the ways things work or introduce limitations (even if they're perfectly defendable from the architectural point of view) then it really needs to be documented. Documented well. Remember (always remember!) that the fundamental principle of CF is abstraction of complexity. It's nice to know how things work under the covers, but we should never HAVE to know - that's the fundamental power of CF. Jim Davis > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Sean A Corfield > Sent: Friday, January 30, 2004 11:15 AM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] More CFMX Excellence with Component Inheritance > > On Jan 30, 2004, at 6:06 AM, Matt Liotta wrote: > > Clearly you are in the minority in terms of expectations in this thread > > So it appears :) > > > Do you think it is expected that cfinclude shouldn't be allowed to > > include the entire function body e.g. the following. > > > > <cffunction name="foo"> > > <cfinclude template="foo.cfm"> > > </cffunction> > > 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++!). > > 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: > > <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. > > Now, when CFMX6.0 came out, there were certainly some strange (and > often glaring) bugs in the ways CFCs interacted with many other parts > of the language: 'variables' scope was totally broken, <cfargument>'s > were not accessible if you <cfinclude>'d the function body, you > couldn't declare 'local' variables or even non-public instance > variables. So, yes, CFCs were broken. > > 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. > > > CFML developers never needed to understand implementation details > > before and they shouldn't now. > > Well, I might take issue with that (but right now I won't bother). > > > Further, such a description doesn't begin to explain why the behavior > > of cfinclud differs depending on the context in which it is used. > > 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. > > 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. > > Hope that helps clarify both my position and the behavior of > <cfinclude>. > > Regards, > Sean > > ---------------------------------------------------------- > 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] ---------------------------------------------------------- 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]
