On Tue, 29 Jan 2013 18:09:44 -0500, Jonathan M Davis <[email protected]>
wrote:
On Tuesday, January 29, 2013 12:10:04 Steven Schveighoffer wrote:
Sound crazy? Ridiculous? Impossible? Insulting?
It seems like it could work, but without a way to explictly make
something a
getter property, it will be impossible to change a property function
into a
variable later without risking breaking code, because then people will
still
be able to call the property function with parens. Using parens on getter
properties has to be illegal for that to work.
I don't think this is quite right.
You can never *exactly* replace a field with a property, or vice versa.
There are aspects that are different for both.
But there are two separate cases here. One is, you define a property that
is specific to a type, and then replace it with a field. The other is
that there is a DEFINED API, and you replace it with a field.
In the first case, yes, you would have to go through and replace ()
instances with ones that do not have it. If your documentation is clear,
then it really is on the user to have made that mistake. With the idea I
specified later where getX would require no parentheses, you could specify
a property that could not be called like a function unless you use the
getX version.
But in the second case, consider for instance a range. A range has an
empty field/property. If you called it via empty(), then your code is
broken for all different types of ranges which use a field (or enum).
In any case, I think there is no getting around that changing from a
property to a field or vice versa will cause problems for existing code.
-Steve
