On Nov 28, 2005, at 5:27 PM, Joseph J. Strout wrote:
At 2:11 PM -0800 11/28/05, Charles Ross wrote:
OK, but why? It would seem that computed properties make a good place
to store constant information that isn't going to change but can't be
stored as a constant.
To me, it abuses the notion of a property. A property generally
implies something you can get and set -- or at least, that can be set
somewhere, even if it's only within the class itself. You're making
properties whose values are NEVER set except at compile time; that
doesn't seem like a property at all to me.
Probably he has been misled by the use of such properties in framework
classes :)
A function, on the other hand, is just something that returns some
information. It may compute it; it may retrieve it from some storage;
it may always return the same thing. It's not something you set
(ignoring "Assigns" methods for the moment). So it's a good fit for a
constant value.
But in the end, it's just a matter of taste. This is the
getting-started list, and I recommend methods mainly because they are
simpler -- computed properties are an advanced feature. But if you
like 'em, then fine, there is no technical reason not to use them for
this.
I'm not sure why computed properties should be considered advanced.
Indeed, it is a relatively small jump from the notion of a property to
a computed property with its get and set methods (I wish for a an
additional "subproperty", Data as PropertyType). The idea of a pair of
methods as an implementation of a property, on the other hand, requires
harder thinking.
--------------
Charles Yeomans
_______________________________________________
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>
|