Sean...
Without going into a legal battle this is to prove my point? Where are your
getters and setters in this bit of code? So that means the development of
this product should be sacked because they do not follow what was it you
said oh yeah
They would not be hired because they don't follow the buzz word of the day
company standard!!
You wonder why I am a little upset over this, you can preach one thing in
one breath but actual code says another thing!!
NOTICE THE PUBLIC VARIABLES, this breaks your recommendations for what was
that word again oh yeah accessor/mutator or how to write robust code what is
so robust about this. It breaks when I pass it a negative value at
development time, which is what I have been trying to point out?
package flex.parser.types;
import flex.parser.SwfEncoder;
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;
}
}
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 9:14 AM
To: CFAussie Mailing List
Subject: [cfaussie] RE: this
On Thu, 1 Jul 2004 08:01:21 +1000, Andrew Scott <[EMAIL PROTECTED]> wrote:
> If Macromedia wishes to use that as a standard that is fine, then
> macromedia should then remove that scope from existence!
Macromedia *Web Team* standard says don't use it. Macromedia *product
team* added the feature.
That's exactly the same situation as Sun and pretty much every compiler
vendor: the language has the feature but 99% of coding standards say don't
use it.
> 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?
If you refused to follow the team's coding standards then, yeah, you
wouldn't be hired. I think that's true of most (all?) companies.
> Now to claim that Macromedia DON'T use the this scope is a very big
> statement I know you can not back up.
I'm talking about the Macromedia Web Team (whose coding standards are
published on LiveDocs). Your comment made me go check the coding standards
and, interestingly, they don't actually forbid "this" scope but I know that
the engineers all know not to use it. Not using public data members is
something so fundamental that it is second nature to them (because they
mostly have OO backgrounds and know not to use public data from their
experience with other languages).
> In either Coldfsuion or your Java
> programming I bet if I looked hard enough I could show you thousands
> of examples where you do!
Their Java programming guidelines are not published on LiveDocs - they're
based on Scott Ambler's "Writing Robust Java" and here's a quote about this
topic:
"Using Accessors
Writing Robust Java Code makes an important structural recommendation
(3.4 The Use of Accessor Member Functions) that bears highlighting:
use accessors instead of directly manipulating data members or class
constants.
According to this recommendation, the only methods that should directly
access a data member are the accessor and mutator for that data member. All
other references within the class should use the accessor / mutator. It
follows that all data members will be private and accessors and mutators
will generally be private or protected.
Only if direct access / update for a data member is genuinely needed outside
the class will the accessor and/or mutator functions be public.
The other important consequence of this recommendation is that instead of
class constants (static final data members), provide an accessor for
flexibility. See 3.4.2.2 Getters for Constants for more detail."
I'd be very, very surprised to see public data members in any of their Java
code.
As for the CF code, well, a lot was written against 6.0 which forced you to
use "this" scope because "variables" scope didn't work. Some of that legacy
code has been reworked to use "variables" scope, some hasn't - due to
time/resource constraints.
Sean
---
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/
