John McCormack wrote:
Consider a Point variable pt:Point(100,200). This generates calls to x() and
y() as expected. But the debugger intialisation of pt causes an uneccessary
call to pt.length() and this inappropriately reset the variable Changed. Why
are getters and setters called uneccessarily by the debugger?
A getter defines the get method of a property. Properties have to appear
transparently as public fields. The Flash debugger has to show the
values of public fields. Thus it has to call the property getter to
display the value. (And it has to store the current value of each field
in the scope tree even if the end-user never expands it, right?)
As an example, let's pretend we have a getter which adds the values of
variables A and B. How is the debugger going to populate a tree view of
the parent object if it does NOT call that getter?
In my view, it's a self-evidently poor programming practice to write a
property getter which makes changes to the property. Falls into the same
category as combining short-circuiting with side effects in a
conditional statement: yes, it works, and it can even be useful, but
it's dangerously opaque.
_______________________________________________
Flashcoders@chattyfig.figleaf.com
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
