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
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Barnes
Sent: Thursday, 1 July 2004 9:09 AM
To: CFAussie Mailing List
Subject: [cfaussie] Re: this
Firstly,
Pull your head in snapper-head, I and Sean aren't attacking you, if i were
i'd prefix my reply with "you stupid monkey".
Secondly,
We are *trying* to illustrate a flaw in how a simple procedure like the one
you outlined can go wrong.
If you want to use the "this" scope, and you feel it rox your world, then
hell do it. In fact if you want to store your shopping cart order in an
application scope, because you feel the word "application" is much prettier
then the word "session" then DO IT.
BUT...
When the time comes, and it will eventually, when someone *ELSE* uses your
application, sees a public property and notices there aren't any
setters/getters around to manipulate data in that property, decides "..oh
its time i added a value to that..", inputs the wrong data and suddenly an
application isn't working and you spend the next hour or so debuging as to
why...
I'll hold up my big banner that says "We told you so.." - You've asked the
question as to why the "this" scope sux in CFMX, yet you still persist in
wanting to campaign to us and others as to how wrong we are so that your
point of view dominates. Simple fact is, its wrong, and its wrong for the
main single purpose in that its public property. Not all people have access
to your source code or look inside a CFC, sometimes its quite possible they
will see an object in its "metadata" form and go take that as face value -
and its quite ok to assume that if you see a public property on an object
that maybe it has some kind of transparent server-side validation going on.
As i have illustrated before it would be *nice* if coldfusion could use its
own public function get myVariable() {} type approach, but it doesn't and so
you have to wear the fact that CFMX is cumbersome when it comes to public
property and type casting.
I'll call you on that challenge by the way.. in that lets have a pepsi
challenge on why its a good idea to use the "this" scope with Coldfusion MX.
:)
Scott.
Andrew Scott wrote:
> Sean,
>
> If Macromedia wishes to use that as a standard that is fine, then
> macromedia should then remove that scope from existence!
>
> My point and I think you missed it, I chose to look at execution times
> as well like I said it is a very complicated framework.
>
> And if you have a company standard that is good, but lets say you had
> a job opening and I came along and applied but choose to see execution
> time as a bigger benefit would I not get hired because I don't see your
full point?
>
> Now to claim that Macromedia DON'T use the this scope is a very big
> statement I know you can not back up. In either Coldfsuion or your
> Java programming I bet if I looked hard enough I could show you
> thousands of examples where you do!
>
> Coldfusion maybe not, it is very spaghetti code to start with. But
> Java I think I could without evening trying!
>
>
> 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: Thursday, 1 July 2004 7:38 AM
> To: CFAussie Mailing List
> Subject: [cfaussie] RE: this
>
> On Thu, 1 Jul 2004 07:19:18 +1000, Andrew Scott <[EMAIL PROTECTED]> wrote:
>
>>Ok maybe this example would be better for you
>
>
> Nope.
>
>
>> I don't need to do encapsulation here, and again this one of many
>>examples in our framework were I don't need to worry about it... My
>>choice not yours,
>
>
> And here we agree. It is *your* choice. And it is my choice to
> recommend folks don't use "this" scope under any circumstances. You
> missed a point I made earlier even tho' you actually confirm it here:
>
>
>>Like I said I understand the risks and the dangers and it is all
>>taking into consideration when I design my component.
>
>
> *You* may understand but a newbie won't necessarily. And newbies tend
> to see code and just run with it. If there is a sense that "this"
> scope is 'good', newbies will program that way and then be very
> confused when everyone starts telling them their code is crap. All I'm
> trying to do is ensure that folks see "this" scope as a very rare
exception.
>
> And if you were writing code in Macromedia, you wouldn't be using "this"
> scope even in the examples you gave - you'd add get/set methods and
> use "variables" scope. And that's our choice :)
>
> Pretty much every coding standard for every OO language prohibits the
> use of public data members - to preserve encapsulation - a term that
> any newbie going anywhere near OO needs to learn and understand.
>
> ---
> 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/
---
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/
