ahhhh... well, I'm sort of there. I realise that there should not be ANY reference to session or Application scope within the CFC because those shared scopes can get changed from external influences.
to be honest, I thought request and server were, perhaps, excusable. obviously not. we're trying to introduce a "kernel" idea as a central point for getDSN(), error reporting, setup settings and in this case utils. stored in server scope, the app MUST NOT run without this singleton object existing. the kernel is created only in one spot and any changes have to go thru only one path. Every other CFC can rely on this kernel for what it needs on a global level. we use the Application.cfm to copy it over to request scope as a snapshot of the data at that point (any changes to the kernel will be picked up on the next request) is it really that bad to bend encapsulation this way? or is there a better way to use this kernel CFC? >>>> <cfreturn request.kernel.utils.arrayostructs(qry) /> >>That's a violation of encapsulation, plain and simple. >>Something Barney and I wouldn't do understood because at that point the CFC is referencing an external scope. But how would be the best way to use such a util function? Instanciate it in the INIT() of every CFC wanting it? thanx barry.b > Forgive me Sean but I can't see the problem. It's one of those things that really can't be explained if you don't 'get' it... encapsulation is a good thing... it helps you build more reusable code. Referencing external stuff (like request scope or server scope) from inside an object is a violation of encapsulation. That's just a fact. Whether or not that violation of encapsulation is important to you depends on how much you value encapsulation. If you don't 'get' encapsulation then you won't value it so it's kinda moot... > <cfreturn request.kernel.utils.arrayostructs(qry) /> That's a violation of encapsulation, plain and simple. Something Barney and I wouldn't do because we value the benefits of encapsulation but something that others would do if they don't yet view encapsulation as important. > but isn't instanciation of objects a performance hit? Depends. And even if it is, the performance hit may well be irrelevant compared to the benefits of maintaining encapsulation. It's that old saw about never optimize unless you know you have a problem and you've tracked it down to something specific... -- _______________________________________________ Talk More, Pay Less with Net2Phone Direct(R), up to 1500 minutes free! http://www.net2phone.com/cgi-bin/link.cgi?143 ---------------------------------------------------------- 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]
