On Mar 9, 2006, at 4:10 PM, Phil M wrote:
On Mar 9, 2006, at 10:39 AM, John Balestrieri wrote:
Hi Phil, all good points, but the points, but the thing I seem to
be missing in my understanding is why they were implemented to not
allow overriding.
Because they are implemented as Properties, and Properties cannot
be overridden.
::edit::
If you do not like this behavior, then submit a feature request.
I understand the principle, I was just questioning the implementation
("questioning" does not mean "challenging"). As I understand it,
computed properties were added so that we did not have to have
cumbersome methods to manage property getting/setting in the same
editor space as our class methods.
It seems we are loosing functionality we had by doing the same thing
with methods, and I'm not seeing the benefit of these computed
properties being handled as properties rather methods.
Computed Properties are designed to behave exactly like basic
properties including the inability to override. This is a design
decision and I don't know the reasons behind the design... it just
is (sorry).
This is exactly what I'm curious to learn.
John
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
