I've wrestled with this question too. In general I've found that I
usually only want to use a getter in situations where I don't want the
user to be able to set the value. In this case, it has seemed more
appropriate to just supply a getMyProperty value, so that it doesn't
appear that the value can be set.
In other cases, I provide only a way to set a specific value, and no way
to read it (mostly because I want to do error checking on the value, and
was too lazy to set up the get functions). In this case, using the built
in method would seem more warranted, but then it is less obvious that
the user of the class should catch an exception, or check to make sure
the value was actually set properly.
One other minor technical thing, is that you can't use Object.watch to
watch for changes on a property that is a getter, which would rarely be
used, but could still annoying for someone later on down the line, who
has to discover this the hard way (like on javascript's window.location,
grrr).
So in general, at this point I try to stay away from built in getters
and setters, and just use normal functions. It seems that if when you
set or get a property, if it is more than just getting or retrieving a
value, then there is no reason to hide those computations from the
programmer using the class.
Kevin N.
Jim Tann wrote:
Hello all,
After a long time of trying to figure which method of using getters &
setters is better I though the best way to get a good answer is to throw
it open to the list.
Do you prefer to use the inbuilt getter & setter functionality?
i.e.
public function get myProperty():Number{ return _myProperty; }
public function set myProperty(intSet:Number):Void{ _myProperty =
intSet; }
or do you prefer using normal functions?
i.e.
public function getMyProperty():Number{ return _myProperty; }
public function setMyProperty(intSet:Number):Void{ _myProperty = intSet;
}
I like the first method as it looks cleaner, but there have been issues
with inheritance where if you overwrite either the getter or setter, but
not both in the child class it gets ignored.
What are your views?
Jim
_______________________________________________
[email protected]
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com