Daniel,"Performance is irrelevant in this situation. You're going to make your code less readable to gain 5 milliseconds? (FYI: That's five one thousandth's of one second.)" You made my point for me. I was trying to advocate the slightly longer, more readable code (like mine and Anthony's). The idea being that the difference in speed is very negligible and therefore the more readable code should be chosen over the one liner."OOP is objects taking to each other. Are you sure your doing OOP? And not quasi-OOP (procedural code dumped into objects)." You're probably right. The owner of my company is *very* old school about his code (read: procedural FoxPro). In some cases he'd rather cut and paste a piece of code over and over instead of writing a simple function. From some bad experience he (and other folks in my company) have had with Java, they see true OO as a very time consuming way to write code. Since what we sell to our clients is the speed at which we can make things happen, he will always do things the way he's always done them. I and another programmer at our little consulting company, believe quite the opposite. However, we are both self-taught. We were hired because we'd written some sort of code in some other language, and then told, "Okay. Go learn this language. You have two days." In my case it was ColdFusion. In his case it was VB. But now almost everything we do is in ColdFusion or FoxPro. The point being that neither of us went to school for this stuff, so no, we're probably not doing true OO. :) This is a fun discussion. :) Chris Daniel Eben Elmore wrote: @Rick Yes elegance requires interpretation. I find it interesting that everyone interpreted it to mean "one line of code". Who taught you that?? @Marlon "the more code you have, the higher the chance of bugs." That's a straw man argument. @Christopher "speed difference between a solution like mine or..." Performance is irrelevant in this situation. You're going to make your code less readable to gain 5 milliseconds? (FYI: That's five one thousandth's of one second.) "struggle in the little company I work for as to when oop goes too far" OOP is objects taking to each other. Are you sure your doing OOP? And not quasi-OOP (procedural code dumped into objects). @the UDF advocates Yes, this is better. The code inside the function needs to be readable/maintainable too. If you're just going to use it as a wrapper for one of your "elegent" one liners, there's not much point. @everyone "an object would be overkill" Famous last words! :) I wish I had more time to debate. I think I'll start trying to come to the meetings again! -Daniel Elmore -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Anthony Frey Sent: Wednesday, September 13, 2006 10:48 PM To: Dallas/Fort Worth ColdFusion User Group Mailing List Subject: Re: [DFW CFUG] Brain Teaser not one liner, not elegent, just different. It does take into account that it may be the only param though. anyway, it took my mind off this jsp crap ive been doing all day, thanks! <cfset params = right(cgi.HTTP_REFERER, find("?", cgi.HTTP_REFERER, 0)+1)> <cfloop list="#params#" delimiters="&" index="i"> <cfif find("numPageID", i) GTE 1> <cfoutput> #getToken(i, 2, "=")# </cfoutput> </cfif> </cfloop> Anthony C. Frey 214-529-1507 [EMAIL PROTECTED] ----- Original Message ---- From: Joe Kelly <[EMAIL PROTECTED]> To: Dallas/Fort Worth ColdFusion User Group Mailing List <[email protected]> Sent: Wednesday, September 13, 2006 4:34:56 PM Subject: [DFW CFUG] Brain Teaser I want to see if someone can come up with a more elegant solution to this problem. Given: CGI.HTTP_REFERER will always have a URL variable, "numPageID=xxx" which is numeric and could be any size number. The HTTP_REFERER may or may not have other URL variables in any order, which could be alphanumeric or numeric The current template needs to pull the value of the "numPageID" URL variable out of the CGI.HTTP_REFERER I'll show my solution in another post so as not to spoil anyone's view on this problem, not saying that mine is best, of course! Thanks, Joe Kelly _______________________________________________ Reply to DFWCFUG: [email protected] Subscribe/Unsubscribe: http://lists1.safesecureweb.com/mailman/listinfo/list List Archives: http://www.mail-archive.com/list%40list.dfwcfug.org/ http://www.mail-archive.com/list%40dfwcfug.org/ DFWCFUG Sponsors: www.HostMySite.com www.teksystems.com/ _______________________________________________ Reply to DFWCFUG: [email protected] Subscribe/Unsubscribe: http://lists1.safesecureweb.com/mailman/listinfo/list List Archives: http://www.mail-archive.com/list%40list.dfwcfug.org/ http://www.mail-archive.com/list%40dfwcfug.org/ DFWCFUG Sponsors: www.HostMySite.com www.teksystems.com/ _______________________________________________ Reply to DFWCFUG: [email protected] Subscribe/Unsubscribe: http://lists1.safesecureweb.com/mailman/listinfo/list List Archives: http://www.mail-archive.com/list%40list.dfwcfug.org/ http://www.mail-archive.com/list%40dfwcfug.org/ DFWCFUG Sponsors: www.HostMySite.com www.teksystems.com/ |
_______________________________________________ Reply to DFWCFUG: [email protected] Subscribe/Unsubscribe: http://lists1.safesecureweb.com/mailman/listinfo/list List Archives: http://www.mail-archive.com/list%40list.dfwcfug.org/ http://www.mail-archive.com/list%40dfwcfug.org/ DFWCFUG Sponsors: www.HostMySite.com www.teksystems.com/
