That is what I was saying Kerry, the function takes care of changing the internals. Yet on the view/presentation you are likely saying it's gallons. Therefore, you are going to have to change both ends. I think the principle is a good one, but what is harder to see is the semantics of where the line is being drawn or where someone says it's wrong to draw the line. It seems like there is an accepted practice (within a social grouping) but the definition isn't completely supported by logic. It's more like if someone thinks they can visualize the point being made even if the examples don't do a good job.
It seems to me that inside a corporate environment you need a standard. That way code is consistent and that allows you to build things like unit testing. (Oh, my thought is there is more value to having a common standard when there is reuse. From what I see there is little reuse in what most of us do. Note... I am not in disagreement with the standard but only question if it's universal dogmatic lines. Perhaps with more time it will be something you learn with experience, more hands on.) Either way... I can see the perspective and it will likely take time to see where the lines resolve the best. Another thing that does make sense is that for universal teaching it's nice to have a guide. (That is mostly what it seems the standard proves to be is a guide for common discussion and application.) OK... so, where's the Unit Testing? (I will start a different thread on that one... heh.) John Farrar -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kerry Sent: Tuesday, August 30, 2005 4:09 AM To: [email protected] Subject: RE: [CFCDev] When to use the THIS scope for a ColdFusion Component? > So you'd deprecate that method, and then add getGasLeftGallons() and getGasLeftLitres() or something I know its only an example off the top of your head, but this does change the interface! So I can see why John would question the benefit. Heres my take on the example - off the top of my head (feel free to pick holes in it...) car.gas returns a int, so then the presentation layer has to decide wether its litres or gallons. and its just a variable name, so all it can really ever do is return a variable. car.Gas() could at first only return a variable as well, but then when your app grows, you have the option make it call several other functions within itself. which makes the app more flexible. so in the future, car.gas() might actually do something like: var fuel = math.convert("liquid","metric",country.getLiquidMeasurement(),gasamount); return i18n.formatLiquid(fuel,country.getISOAlpha3()); all that, and your presentation layer is still only calling car.gas(), no need to change anything except the contents of the function. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Farrar Sent: 30 August 2005 03:36 To: [email protected] Subject: RE: [CFCDev] When to use the THIS scope for a ColdFusion Component? That sort of make sense. (But the calling code has to know the object is no longer reporting gallons also... isn't that a violation of the encapsulation concept?) The second example has merit... since age is always relative to the time checked. So unless you could have a variable that reported like a method there would be an issue. Thanks.... John -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert Sent: Monday, August 29, 2005 4:19 PM To: [email protected] Subject: Re: [CFCDev] When to use the THIS scope for a ColdFusion Component? What if the units in the DB change from gallons to litres? You don't want getGasLeft so start returning a value 3.8 times larger than expected. So you'd deprecate that method, and then add getGasLeftGallons() and getGasLeftLitres() or something. You don't get that protection with instance variables, because as soon as the switch happens, the instance variable's semantics change, and with no indication. Another example is getAge(), because you very likely aren't storing an 'age' variable, but rather than 'dateOfBirth' variable that needs computation. But the calling code shouldn't care (or even be able to tell); that's encapsulation. Autogenerated get/set methods aren't any more helpful than just exposing the raw data members. The encapsulation only comes when they're actually encapsulating something, usually a conversion from the publicly exposed properties to the actual internal representation. cheers, barneyb ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm 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' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm 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' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
