Dude,
You're skating uphill. Personally i'd hate to be your replacement when you leave a company, for the below reasoning.
As I said, its bad, in other languages, yes whatever etc, but CFMX it is BAD and i'll call any programmer who doth use it in both runtime/design/development (which incidently in many ways are the same, just two different time-planes) BAD PROGRAMMERS.
I've been in many a situation where i've had to pick up the mess left behind by people who think singular in that they do these little small annoyances, and me being the newbie in the company not knowing past discussions and why's hows etc find shitholes like direct accessing public properties or other such cases, all because someone didn't think outside their pod or thought it would be cooler to shave a .10ns off the compile time. (Personally if a setter/getter tips your code over the balance in compile time, you have bigger problems).
There are reasons why *a lot* of people have and will say its "BAD" or "DONT USE THEM PERIOD" its not so we can shit down on you from our OOP throne in the sky, its simply we are trying to prevent you from some overall pain ahead. In your case, this is an ignored warning and well, you'll find out the hardway down the road i'm guessing...or hell you may be one of these guys who gets away with it, cool good for you, happy you can plough on in life bypassing the rule that most live by. Hope your a rich man in the end, and you can flip me in my beatup datason the bird as you wizz by in your porsche for it all.
Thats my last thoughts on the matter and before i go, i'd like to flog that dead horse on more time in saying:
What if i set the Rect.xMin = NaN?
How will your calculations go then. Its a classic example as lets say yo u use Flash/DHTML to work out the actual value for your dynamic object x positions minimum based on stage/screen area and it returns Not a Number instead of a numeric value.
By the time you've figured out its not numeric, your deep inside some various methods in your case the equals()
Anyway, Scott.
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?
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.
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, I just want to point out that there are cases that you can use it safely. Sometimes execution speed is more important other times it is not, and I'll say it again I understand the dangers but you had to again throw the importance of it in my face again in this email.
The 2 examples I gave don't rely on the breaking of the rule of encapsulation, that would be like this bit of code in Java, there is no checking to see if I set any of the variables to a -1. 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. As a developer you can not predict everything, but you can certainly make sure that at runtime these things are encapsulated, at design time there is no need for it!
Rect rect = new Rect(); Rect.xMin = -1;
public class Rect {
public int xMin = 0; public int xMax = 0; public int yMin = 0; public int yMax = 0;
public Rect(int width, int height) { xMax = width; yMax = height; nbits(); }
public Rect() { }
public Rect(int xMin, int xMax, int yMin, int yMax) { this.xMin = xMin; this.xMax = xMax; this.yMin = yMin; this.yMax = yMax; }
public String toString() { return "" + (xMax - xMin) + 'x' + (yMax - yMin); }
public int nbits() { int maxCoord = SwfEncoder.maxNum(xMin, xMax, yMin, yMax); return SwfEncoder.minBits(maxCoord, 1); }
public int getWidth() { return xMax - xMin; }
public int getHeight() { return yMax - yMin; }
public boolean equals(Object object) { boolean isEqual = false; if(object instanceof Rect) { Rect rect = (Rect)object; if(rect.xMin == xMin && rect.xMax == xMax && rect.yMin == yMin && rect.yMax == yMax) isEqual = true; } return isEqual; } }
Look we can go around in circles, or we can look at the fact that we both understand the dangers. All I am saying is leave a methodology to just that, don't put it in a way that makes everyone look bad because they choose another way of doing something. Like I said my way is development time and I would like to see any language that could predetict a programmers thoughts!
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.
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
--- 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/
