Scott & Sean, This is what annoys me, you both have come to the assumption that the snippet of code that I have supplied is bad, because it can't be type cast!
Let me tell you something here. This example is part of a framework that is setup at design/development time, hence I used this example because there is no type casting necessary. This snippet produces HTML output and in Coldfusions eyes if a developer was to set the width to 100x for example the html will look weird and you would know why. Now if it was runtime, or dependant on user interaction I would agree with you. However all our user input/interaction is caught and checked before a call like this would also be called, but this is our framework and it works well. I took the liberty of not using setters and getters, because the framework is complicated to start with and I didn't want to use extra code to bog down the framework. Again it was a personal choice. Don't attack me because I choose to see the benefits of not using it in within our framework, I accept that a developer needs to be aware of such things that you both point out and if coldfusion did not treat everything as a string it would be a different story, but it does so we have to look at ways to protect this. However just not in my case, every form a users has to submit is type checked before ever getting back into our framework.. Sean you can't abuse my code, my code is design/development time so if you want to try by all means try.... Like I said earlier you can give a thousand reason why to do it your way, and I can also give you ways to do it my way. Doesn't mean I don't understand your reasoning, it means I choose when and if I need to do it either way that suits the needs of the framework at the time I write it. But to tell someone it is bad because it breaks encapsulation. What the hell does that say to a newbie nothing. Now if you said because coldfusion treats everything as strings it would be best to take this into consideration when designing your CFC, don't confuse someone who is already confused to start with. Regards Andrew Scott Technical Consultant NuSphere Pty Ltd Level 2/33 Bank Street South Melbourne, Victoria, 3205 Phone: 03 9686 0485 - Fax: 03 9699 7976 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Corfield Sent: Wednesday, 30 June 2004 2:54 PM To: CFAussie Mailing List Subject: [cfaussie] RE: this On Wed, 30 Jun 2004 10:29:45 +1000, Andrew Scott <[EMAIL PROTECTED]> wrote: > But to plain say don't is > not right for those wanting to know. The problem is that the very rare situations where it is right are usually hard to explain. It's much safer to teach 'newbies' that public data members are a point blank 'no-no' and then when they have some experience tell them that there are one or two situations where it is sort of OK to use it... > <cfset oInput.Caption = "Test" /> > <cfset oInput.Width = 100 /> > <cfset oInput.Display() /> And I'd say this is a point blank bad use. You'd be better using get/set methods. Width in particular should be type-checked to be numeric (perhaps even range checked as well). That requires a set method (which is exactly the point of this whole exercise). > <cfcomponent> > <!--- Default values ---> > <cfset this.Width = 100 /> > <cfset this.Height = 100 /> > <cfset this.TextColor = "#FFFFFF" /> > <cfset this.BackColor = "#cccccc" /> So I can say obj.Height = "I'm not valid" and completely screw your object... > Now in this case here I have a pile of default values that might or > might not change, so in this example why would I want to pass the > values that do not change each and every call to the display function? That has *nothing* to do with set/get methods. You'd never need to pass the values into "each and every call"... > Now I could use oInput.SetWidth(100) but again it's a choice not a > must do way of doing things? See above. I can totally screw your object over if you use "this" scope instead of get/set... That's what encapsulation is all about. That's one of the benefits of OO - it can prevent accidental (or even intentional) abuse of your code... --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
