G'day. I've changed the thread title because I'm not interested in how whys and the wherefores of <cfinclude> (currently), I'm more interested in this "anomalous" behaviour we're seeing in CFCs. I think the two are related - but not the same - conversations.
> This is interesting because these UDFs still respect the notions of > PUBLIC and PRIVATE, kind of like they *were* almost methods, but... > not. > The <cffunction> tag always allows you to specify the access=attribute, regardless of whether it is inside <cfcomponent> or not. Sure, but PUBLIC and PRIVATE are meaningless concepts to a UDF - which you're claiming <cfinclude>`ed functions are. HOWEVER, when these UDFs (not methods) are part of a CFC, then the PUBLIC and PRIVATE *do* now mean something. >Nope. It's designed that way. And it makes perfect sense when you understand the model behind the language. I can see what you're trying to explain. But I hesitate on the "perfect sense" bit. >Correct. They don't show up as methods in the metadata (even if you put access="public" on them - because of course that is irrelevant in a standalone UDF). Although you can still call them as methods of the instantiated object. myObj.myUDF() >From calling code. This - too - is at odds with how you're saying <cfinclude>`ed UDFs are supposed to work "by design". IFF what you are saying is the intended case, I wold have thought the UDFs would be not only invisible to the calling developer (they are), they should be unavailable to the calling code (they're not). Basically, all I'm seeing is that the included UDFs *are* handled exactly as methods of the component, other than the fact they don't show up in the component meta-data, and they chuck that error I first mentioned. And the apparent "we really meant it to be this way, honest" implementation is more a hindrance than a help. 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]
