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("&nbsp;",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]

Reply via email to