I think the debate here seems to be a disjunct between a procedural view of the world (pre-CFCs) and an object-oriented view of the world (CFCs). I actually wonder whether using cfinclude inside a cfc is a good idea at all. Its not that I don't think the idea of being able to include functionality from other libraries in a cfc is a bad thing, but I think this discussion highlights that it semantically confusing to allow use of cfinclude inside of cfcs.That is an interesting point of view considering that C++ is widely regarded as the language that brought OO to the masses and includes are a very important part of C++.
Wait, wait, don't kill me. I understand that many don't want to know about implementation details, etc. and want components to work like pre-CF6. The problem you face if you want components to work like your procedural code is that they cease to add real value at that point. The big value added is that you are forced NOT to create code with undocumented assumptions. CFincludes may be a nice way to slice code up in into manageable bits, but how many times have you seen someone with a bunch of bugs caused by includes that a)didn't have all their variable declared with CFParams or b)resulted in variables switching values unexpectedly because of the inability to scope them privately. I have seen several posts to this very list on problems with recursive code caused by folks forgetting to scope their vars. In summary: encapsulation is a good thing, it protects you; includes don't allow you to encapsulate, so they give you a dangerous level of flexibility.While bugs may have been found through the use of includes that doesn't mean the includes are the problem. And while includes don't provide a separate namespace (nor should they), that doesn't mean you can't scope variables local to the include. For example, consider the following, which I used heavily pre-MX since custom tags where so slow.
<cfset local = pushStack()> <cfinclude template="whatever.cfm"> <cfset local = popStack()>
Further, the scoping issues you mention would exist whether or not includes did.
I think what people want is the equivalent of Java's import statement (well, ok, it's what I want). If I have all of my cryptographic methods rolled up inside crypto.cfc (eg MD5Hash()) so that I can use them from whereever by instantiating a crypto object I would like to be able to do something like:Java's import statement just clues the compiler into how to resolve namespaces. What you really want is the ability to call Java static methods without cfobject. With that the above example would be rewritten as.
<cfcomponent>
<cfcimport package="bar.foo.util.crypto"/>
...
<cfscript>
test= MD5Hash('ChipTemm');
...
I know that we are able to use CFInvoke, but in my experiments this costs the same as instantiating the object and invoking the method. I want to be able to invoke the crypto class' static methods without the cost of instantiation. How does this differ from a UDF library include? Well, for one semantically I won't expect cfcimport to act like cut'n'paste. I will expect it to act like a CFC.
<cfcomponent>
...
<cfscript>
test = bar.foo.util.crypto.MD5Hash('ChipTemm');
...Now once you had the above capabilities it might be interesting to add some namespace syntax sugar, but considering cfimport already exists I don't the import would be used as the name. Hopefully no one gets the bright idea to get inspiration from .NET for fear of seeing a cfusing or cfwith tag.
So I guess my point is that I agree with Sean that includes "...clearly should not behave like cut'n'paste.." in the context of CFCs. BUT, I also see the point of most of the other commentators on this thread that CFInclude will be expected by CF veterans to behave as it always has. I would say the confusion could be addressed by a CFCImport tag/function in conjunction with changes to the docs to indicate that CFIncludes are not a best practice when used in CFCs.Why should includes not behave that way? Sean brought up the point about namespace collisions in regard to the use of includes in the body of a CFC. Certainly, that problem could be solved by the compiler so that things worked as expected, so I think it is a valid point, but not a good reason. However, I don't see any valid reason why includes can't be used for function bodies.
-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]
