On 12/11/2011 2:56 AM, David Nadlinger wrote:
On 12/11/11 10:04 AM, Mehrdad wrote:
On 12/11/2011 12:57 AM, Andrei Alexandrescu wrote:
I think you should write:
auto copy = this.save;
Ah good point, I forgot about that. Idk then.
(You forgot the parentheses though. :P)
No, it's correct like that, save() is a @property.
Even though I recently updated Phobos to compile with -property
enabled, I agree with Andrei here that in many cases there will be no
perfect consensus whether a given member should be a @property or not,
thus potentially adding an extra source of complexity, or rather
annoyance.
David
Whoa what?! I didn't know save() is a @property. In that case I stand
corrected. :-)
Nevertheless, I think that makes no sense. :P If something isn't a
"property" of something else, it shouldn't be marked as such.
But there are more reasons than that...
I have found Microsoft's guidelines for C# to be great for general usage
of the word @property:
http://msdn.microsoft.com/en-us/library/ms182181.aspx
Specifically:
"Properties should behave as if they are fields; if the method cannot,
it should not be changed to a property.
Methods are better than properties in the following situations:
- Calling the method two times in succession creates different results.
- The method performs a time-consuming operation. The method is
perceivably slower than the time that is required to set or get the
value of a field."
Since both of these can be true for all but the most trivial kinds of
ranges (e.g. file-system-related enumerators/ranges would very likely
need to re-open a handle to a directory in order to traverse it, which
is both relatively time-consuming AND returns a different result every
time, and could even unexpectedly fail due to permission/connectivity
issues), I don't think it makes sense for save() to be a @property.
