>This doesn't create a method - the functions defined in inc.cfm are 
callable within the component but they are not part of the component. 
That means the function in inc.cfm cannot override methods in the 
parent class - and therefore you are trying to declare f2 twice (which 
is illegal).

Sure.  Obviously that's what's going on.  Again (harking back to a
thread last week) that doesn't make it sensible.

>It is implemented this way so you can <cfinclude> a function library 
into a <cfcomponent> tag and access the UDFs in it

This is interesting because these UDFs still respect the notions of
PUBLIC and PRIVATE, kind of like they *were* almost methods, but... not.

This got me thinking that maybe one could have a PRIVATE UDF in a
library file: only accessible to the other UDFs in that library.  But...
No.

It actually sounds to me as if it's exactly what I identified it to be,
to be honest... Another bug with CFCs and <cfinclude>.  I'm sitting here
and reflecting on how good the implementation of <cfincluded> files
within methods was in CFMX60.  Now that was fun to work around.

But hey... Sh*t happens: show me some code without bugs in it!


> - without polluting the methods in your CFC.

Not quite sure what you mean there.  You mean in the meta information?
The component browser?  I can see kind of why you might want to do this,
but I don't think "oh, functions that are <cfincluded> are like
'uber-private'" is really the best approach there.  Hey, I reckon even
having access="uber-private" in the function declaration makes more
sense than that.  But... YMMV.


>If I recall correctly, you can also 
<cfinclude> a function library into a <cffunction> tag - which makes 
the UDFs available just inside that method.

I just tested this and indeed it's the case.  That's quite useful to
know (and always good to learn the good with the bad!).

Cheers.

Adam
----------------------------------------------------------
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]

Reply via email to