On Wed, Jan 30, 2013 at 07:49:58PM -0500, Steven Schveighoffer wrote: > 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). [...]
Actually, this got me thinking. The range API only requires that .empty evaluates to a bool, right? It doesn't matter if it's a function, a public variable, or an enum, as long as it evaluates (or can be evaluated) to a bool. Some ranges indeed do define .empty as an enum (c.f. infinite ranges), so you couldn't take the address of .empty. Now consider class/struct fields in general. It's entirely possible that a particular class starts off with some fields defined as enums (of the manifest constant sort), say as an enum string. Later on, you may decide that the value should be changeable, so you make it a string class variable. Yet later, you may decide to implement a getter/setter for it for whatever reason. In the process, the only time it's valid to take the address of the field is when it's a string variable. So in that sense, the API of the class really only should specify that field xyz is a value of type string; user code should not depend on its particular implementation (enum, variable, or getter). Marking fields as @property is starting to make more and more sense. T -- BREAKFAST.COM halted...Cereal Port Not Responding. -- YHL
