Overall, Simon's post led me to think that people may have gotten the wrong impression from my posts on this topic.  

First, I am, in no way, advocating the use of the &lt;cfinclude&gt; tag <strong>inside</strong> of a CFC's method.  That would be insane.

Second, nothing in a &lt;cfinclude&gt;-style Mixin template should live outside of a &lt;cffunction&gt;.

Third, nothing in the Mixin template's &lt;cffunction&gt; should add to, and preferably not alter the existing scopes of the target CFC - the Mixin's methods should be observational in nature.

Ok, on to my reply:

<em>Joe'd like me to elaborate, so I will.</em>

Thanks Simon!

<em>Code within a &lt;cfinclude&gt; is neither encapsulated nor parameterized.</em>

I think you're taking my use of &lt;cfinclude&gt; very far out of its context.  It's being used only to bring &ltcffunctions&gt; into an existing CFC ? nothing in the included .CFM exists outside of (encapsulated, parameterized) &lt;cffunction&gt; tags.  

The code within the &lt;cfinclude&gt; I discussed is both encapsulated and parameterized ? not in an Object sense, but in a Function sense, because a Mixin is *not* an Object, but more like a fragment of functionality.  It's a template, not a component.

The call to include the code is also parameterized.  I needed an API that was limited in scope, making Mixin implementation simple and limited.  In fact, the only parameter I wanted to be able to pass was the .cfm file to use as a template.  &lt;cfinclude&gt; is exactly that API.

<em>There are some basic rules of OOP that I firmly believe in and apply to CFC use. One is that all business logic belongs in CFC methods.</em>

Agreed ? but how those methods get into an instance doesn?t necessarily need to be from a .cfc file.

<em>Another is that CFCs don't ever display anything ? their methods are data in and data out.</em>

100% Agreed.  

<em>Given those two facts, what good can come from using an include within a CFC method?</em>

If you look at what I did, I never used a &lt;cfinclude&gt; inside of a CFC method.  I think doing so would be pretty silly.

<em>If the thing being included contains business logic then that code should be in a method.</em>

All of the business logic in the &lt;cfinclude&gt; was in methods.  That?s the point ? importing of methods.

<em>If anything, this [code in a method] is more reusable than having it in an include file.</em>

The include *only* contains methods that need to be re-used across CFCs without inheritance.  I?m not sure you read what was being &lt;cfinclude&gt;?d in my example?

<em>If the thing being included generates output, it's OK for that code to talk to CFCs but should never be used by a CFC (since they shouldn't be writing to the screen).</em>

100% agreement.  (S)he who &lt;cfinclude&gt;s something into a CFC that creates output has gone way, way astray.

<em>I'm still waiting for someone to give me an example where using inside of a CFC makes more sense than having all of your logic in components.</em>

?Mixing? is the only example, and only case, where I can find &lt;cfinclude&gt; as being appropriate in a CFC.  Even in this case, the included CFM would have to follow strict rules:  no output, no code outside of &lt;cffunction&gt; tags, and preferably ?observation-only? interaction with the private/public scopes of the target CFC.

It?s a very dangerous thing to do, with limited (good) application.  I?m up front about that, and I?m taking steps with further Model-Glue development to eliminate the reason I?m doing it in the first place.  The example I blogged is about the only good place I can see to do what I did.

<em>Mixins appears to me like a convoluted way to implement the Aspect Oriented Programming technique of 'weaving'.</em>

Yes, it?s similar.  Weaving and Advice are somewhat more advanced AOP concepts that deserve much more robust mechanics than &lt;cfinclude&gt;.  

I used &lt;cfinclude&gt; instead of implementing my own AOP mechanics because it?s intentionally simple and limited, and not convoluted in the least.  I needed a mechanism to statically add a template of methods to a CFC ? and &lt;cfinclude&gt; works like a charm.

<em>Weaving aspects is an interesting idea, but I wouldn't choose to use &lt;cfinclude&gt; in order to implement it.</em>

Neither would I!  Doing AOP cleanly in CF would require a library to not just provide method injection/inflection mechanisms, but one that could also resolve the injected/inflected methods and their dependencies as well!  Come to think of it, this already sounds familiar.

<em>this entry is pretty long already, but if anyone out tere would like to see me implement AOP in CFML, I don't mind doing it.</em>

See ColdSpring AOP ? it's already been done, with the full power of an IoC container behind it :)