Possible @property compromise

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Jan 30 17:14:10 PST 2013


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
> <jmdavisProg at gmx.com> 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


More information about the Digitalmars-d mailing list