Joe... relax... this had nothing to do with encapsulation. It was a udf (code reuse... not encapsulation) and someone asked how to get a udf in the request scope... just pulled something handy from an example I had and converted it to request scope. Go to be an get some sleep... this was just answering that specific question.
And... not just repeat string... run the code... see what it does before asking... you might figure it out. It's a neat trick. And if you want to do it with cut and paste... do it. I won't fire you either way! (What is it with you guys and "you would never work for me", "I'd fire anyone..." ... you guys must be impotent and compensating! :) Feel a need to beat your chest or what? John -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Rinehart Sent: Friday, October 01, 2004 9:20 PM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] Function Libraries Sorry if I'm stirring a cold pot by coming in late, but this thread tweaked me. Actually, the following function tweaks me: <cffunction name="udf_selectColumn"> <cfargument name="content" type="string" required="Yes"> <cfargument name="length" type="numeric" required="yes"> <cfset var local = structNew()> <cfset local.myReturn = arguments.content & repeatString(" ",arguments.length-len(arguments.content))> <cfreturn local.myReturn> </cffunction> John, if your argument is against unnecessary encapsuation, why provide a function that solely serves to abstract the action of a single core function of the language (repeatString)? I could understand it if it was an improvement on L(/R/C)Justify that let you specify a character to justify with, but your function kind of shoots your argument in your foot. The majority of time that I see CF developers breaking encapsulation rules is not out of necessity, but laziness and/or ignorance. And while I may not have 25, or even 10 years of professional IT experience (laws here prevent child labor!), I do know that laziness does nothing but cause more work in the end. Sure, it may be easier to go ahead and have your CFC reach out to CGI, but it's a bad idea. For practical example, if I was doing something based on user agent, it'd make it a pain to test the response given unless I could explicitly set the agent value and examine results - I'd have to actually install the browsers I'm testing response for. Looking at features in for future versions of CF, it's just plain reckless. I think it's our responsibility as programmers to not just specify and write our code for support of the status quo, but to look ahead, and insure we're not causing ourselves and others headaches later because we didn't feel like a few extra keystrokes. Heck, I'd fire anyone working for me who didn't believe this. -joe ---------------------------------------------------------- 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] ---------------------------------------------------------- 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]
