Dave...what OS do you use? Could you point out the OS that is "Fully Encapsulated"? That would be a good project for someone to create to show us the evils of all the other systems. HEH... and again... system variables... and program variables are not the same issue.
On the point that going to a new system (based on scope conflicts) could make the CFC's obsolete. Does that mean if the interface has to be updated for the new system that encapsulation isn't any good either. Your arguments fail in critical thinking. You should go take a course in critical thinking to see if you could prose your argument better. You may have a point... but you haven't made it yet. Further more... I think Sean's thoughts about encapsulation are "mostly" correct. My debate is the thinking that it is an "absolute rule". I am not likely to agree that calling a cgi variable inside a CFC is a violation of good code. Start there... and I would honestly like to see it if there is a point. Sean supported the point by saying it violated encapsulation. That is what we call circular reasoning. Lastly... someday we will do away with windows. There will be a better way. So... do you think they should have stopped at windows 95? Windows NT? Which version would have been good enough for you? John -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Ross Sent: Thursday, September 30, 2004 4:19 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Function Libraries John, Take a computer science course, and if the instructor says "yeah this whole encapsulation thing... don't bother", come back and tell us. Otherwise, I don't see how the burden is on Sean to make a supporting argument to something that you can find in every single software engineering textbook out there, with chapters upon chapters of information as to "why" (not just "cuz we say so"). Anyways... you want "Separation in API of Tiers (Data, Logic, Content, Presentation)". So if you have a data-model CFC, which directly references the request scope, that is in clear violation of something you claim to support. What if some day someone clever figures out how to make apps interact with your CFC's without the use http? (*hint*)... that will pretty much make your request-scope-dependent CFCs fall flat on their face. Same thing with frameworks... what if someday you want to use framework x because it does y... oh but wait you coded all of your business logic to rely on something provided by the original framework you used and has become obsolete or unsupported. These are just a few benefits of encapsulation, and trust me there are many, many more. -Dave ---------------------------------------------------------- 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]
