Andrew Scott wrote:
Scott,
But you have thrown your opinion down my throat! I have never asked the question why does it suck, were did you dig that up from?
Ok, don't know if there is any point weighing into the thread at this point but here goes. Lots of useful technical discussion but also some unnecessary flaming. Andrew in terms of opinion throwing, I think heckles were raised a little by your "I so laugh at this statement" (29/6/04 11:18AM) response to Spike's post. You awoke the sleeping might of Barnsey's send button and it was on for young and old.
Plenty has already been said about why encapsulation, getters and setters are A Good Thing.
Scott, my examples are not runtime they are design/development time and that my dear fellow is a lot different than you are throwing back at me. I understand the dangers at runtime, I understand that you are seeing this with blinkers.
I don't understand the distinction you're making between design/development and runtime - all mistakes and bugs are introduced at design/development time and then stop things working at runtime. As far as invalid method parameters go they're just as likely to come from developer typos and brainos during development as they are from data entry errors in a user form or a dud webservice return value at runtime.
If someone asks the question like Taco did, should I turn around and so not
to use the this scope?
It is like everyone hears that it is bad, so it must be bad. Because someone has found a flaw does that mean we should not use it, no I don't think so. I am defending that under certain circumstances it is ok to use, and to quote Sean on this he has even said that under certain circumstances it is ok to use it... Just that MM choose to not use it.
I will say this again, I am aware of the dangers of using the this scope. And you don't need to keep drumming it in, and both of you have done this right from the word go.
I am not the one you need to convince on the dangers of it,
There have been several attempts to separate the "what is ok to code in the privacy of your own business/project/framework" (anything) and "what is generally accepted as best practise". The problem is that advice posted on this list (with over 600 subscribers), if not otherwise qualified comes with the assumption that it's based on best practises, so when advice is given that others believe isn't best practise, they feel duty bound to put in their version of things - not necessarily an attack on the original advice, just a clarification of what best practices are around for people who don't know yet.
Sometimes execution speed is more important other times it is not,
I've never noticed a particular performance hit from getters and setters. If you're really worried about performance to the exclusion of all else you wouldn't use CFCs at all, or at least avoid too many calls to createObject (try timing a call).
Why would you want to, this is at development time and why would I waste execution time to put a check to see if the value set is a -1 when the developer should know that it is 0 - n on any of the values.
There are lots of things that increase execution time to improve code readability, maintainability, reuse - e.g. separating code into includes, tags and modules etc adds non-trivial overhead - setter methods are just another one of these devices.
And just because I choose NOT to use setters and getters all the time, in rare cases I don't think it is necessary doesn't mean that I am a bad programmer. Nor does it mean I don't understand the dangers, nor does it mean that I did not think of the consequences that it might imply.
Seriously, I don't think anybody was trying to say this Andrew. There were a few failed attempts at humour, but then that's why Scott isn't hosting Rove Live (also because Rove Barnes would frankly be a very silly name).
Cheers, Robin
------------------------------------------------- Robin Hilliard Partner RocketBoots Pty Ltd Professional Services for Macromedia Technologies m +61 418 414 341 f +61 2 9798 0070 e [EMAIL PROTECTED] w http://www.rocketboots.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/
