Hey Sean, thanks for the response. It is supposition, in fact, it's my original question. We've had a few discussions on this list about var scoping, and I was still unclear on how CFC would behave if you didn't var scope the return values from tags like cfquery, cfhttp, cfftp, cfcatch etc.. Based on what I've gathered from conversations on this list, if you don't var scope those variables, they will (by default) exist in the Variables scope. If it's in the Variables scope, doesn't that mean that it's shared among all requests using that instance of the CFC? Perhaps there's something obvious that I'm missing here.
"If you don't think CFCs are worthwhile, fair enough, but I think you need to look again" I love CFCs and I'll never go back. I'm just not convinced that it's worth it to try to use CFCs to implement typical OOP design patterns. There are a few instances where using OOP concepts makes things cleaner, but in most cases I'm finding that the implementation becomes convoluted. Being a consultant means that I need to make sure that my client's future developers will be able to understand, debug and upgrade my code, and it just seems like they would have to be far too familiar with the intricacies of CFCs to make it practical. I prefer to use CFCs to group related functions into files and use files to separate business logic from database logic. It makes for a succinct file system full of self-documenting functions (much nicer than pre-CFC days). For all you macromedia guys reading this list.. sorry for the "slapped together" comment. I guess I was in a bit of a mood that day. CFCs are awesome and I agree that they're the single best improvement in ColdFusion since custom tags. - j. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sean A Corfield Sent: Wednesday, November 12, 2003 9:32 AM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] Native CF tags and local scope On Thursday, Nov 6, 2003, at 11:48 US/Pacific, Jay Gibb wrote: > In my previous example, if multiple requests were using the component > in a persistent scope (like Application.myCFC or whatever) it would > cause > problems if more than one request happened to get into that > <cfcatch></cfcatch> simultaneously. Is this supposition or do you have empirical evidence that this is, in fact, the case? I ask because we use exception handling heavily in CFCs that are stored in shared scopes and we have not experienced the problems you seem to be talking about. > Without 'var' scoping the cfcatch > structure, I'm running a really good possibility that one request will > get > the cfcatch structure generated by someone else. I don't believe that is the case (but I can check with the product team). It seems to me the cfcatch structure would have to be unique to each request - otherwise people would be tripping over that issue all the time (and would have seen it in pre-MX versions of CF as well!). > This is one more reason not to use CFCs for anything more than a code > organization tool for a procedural system. I can't help but think > that it > was slapped together by Macromedia as an after-thought. CFCs went through a lot of design iterations and were honed throughout the entire MX lifecycle to reach where they are today. I'd hardly call that "slapped together". macromedia.com uses CFCs heavily and the team that built the apps has a lot of hardcore Java and C++ background so they understand OO and design patterns pretty well. They're pretty happy with CFCs. Mach II is another example of using CFCs to successfully build OO software (and we're adopting Mach II at Macromedia - hear me talk about our experiences at BACFUG in December and - in more detail - at MXDU in February). If you don't think CFCs are worthwhile, fair enough, but I think you need to look again... Sean A Corfield -- Director, Architecture Web Technology Group -- Macromedia, Inc. tel: (415) 252-2287 -- cell: (415) 717-8473 aim/iChat: seancorfield -- http://www.macromedia.com An Architect's View -- http://www.macromedia.com/go/arch_blog MAX, the 2003 Macromedia User Conference November 18-21, Salt Lake City, Utah Register today at http://www.macromedia.com/go/max ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word '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] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word '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]
