@property has gotten a lot of flak lately, and I think the unenthusiastic implementation of it really hasn't helped.

BUT... there are a few problems with the original non-@property implementation that are fixed by having additional syntax (well, if it was properly implemented):

1. Treating any old function as a setter.  This is the writeln = "hi"; mess
2. Forcing you to use 2 sets of parentheses when returning a callable type.

However, we have seen the addition of two problems with @property.  First is when UFCS was introduced.

@property int iprop(int val) {...}

can be called as:

52.iprop;

or

iprop = 52;

Second problem is, when ref returns are used on properties:

@property ref int iprop();

auto x = &iprop;

Should x be the delegate for iprop, or call iprop and get the address of the return value?

ASIDE from the disdain that many developers have towards @property, I think above anything else, that the first problem @property fixed above is essential to the freedom of naming functions for API designers.  The second problem of getting delegates via properties is fixed,  so it would be a step backwards if we just removed @property.

So in light of all that, I propose a compromise:

1. Deprecate @property.
2. When the compiler encounters a field setting like this:

x.y = ...;

If a y field exists on the aggregate represented by x, then that is the assumed member being referenced, and compilation continues normally.

If there is no y field, then then the compiler ALSO tries:

x.setY(...);

It is important to note that:

x.y(...);

does not compile, y is not just another function.  To call in function form, you must call:

x.setY(...);

That takes care of setters, AND takes care of the new problems with @property.

3. Parentheses remain optional on functions, allowing the creation of getters as before @property.

However, this does not fix the delegate problem.  To fix that problem, we can use the complementary getY to allow specifying a getter that does not absorb parentheses.

One problem I will note with this scheme, some Unicode symbols that may be valid D symbol starters may NOT have an upper/lower case, making it impossible to use those as properties.  But I admit having an English bias so I don't see this as a large problem.  Besides, "set" is already English.

Note, I've been doing a lot of Objective C lately, and I kind of like the property scheme there (this is quite similar).

Sound crazy?  Ridiculous?  Impossible?  Insulting?

What do you think?

-Steve

On Tuesday, 29 January 2013 at 17:10:00 UTC, Steven Schveighoffer wrote:
> @property has gotten a lot of flak lately, and I think the unenthusiastic implementation of it really hasn't helped.
>
> BUT... there are a few problems with the original non-@property implementation that are fixed by having additional syntax (well, if it was properly implemented):
>
> 1. Treating any old function as a setter.  This is the writeln = "hi"; mess
> 2. Forcing you to use 2 sets of parentheses when returning a callable type.
>
> However, we have seen the addition of two problems with @property.  First is when UFCS was introduced.
>
> @property int iprop(int val) {...}
>
> can be called as:
>
> 52.iprop;
>
> or
>
> iprop = 52;
>
> Second problem is, when ref returns are used on properties:
>
> @property ref int iprop();
>
> auto x = &iprop;
>
> Should x be the delegate for iprop, or call iprop and get the address of the return value?
>
> ASIDE from the disdain that many developers have towards @property, I think above anything else, that the first problem @property fixed above is essential to the freedom of naming functions for API designers.  The second problem of getting delegates via properties is fixed,  so it would be a step backwards if we just removed @property.
>
> So in light of all that, I propose a compromise:
>
> 1. Deprecate @property.
> 2. When the compiler encounters a field setting like this:
>
> x.y = ...;
>
> If a y field exists on the aggregate represented by x, then that is the assumed member being referenced, and compilation continues normally.
>
> If there is no y field, then then the compiler ALSO tries:
>
> x.setY(...);
>
no, just no.

> It is important to note that:
>
> x.y(...);
>
> does not compile, y is not just another function.  To call in function form, you must call:
>
> x.setY(...);
>
> That takes care of setters, AND takes care of the new problems with @property.
>
> 3. Parentheses remain optional on functions, allowing the creation of getters as before @property.
>
> However, this does not fix the delegate problem.  To fix that problem, we can use the complementary getY to allow specifying a getter that does not absorb parentheses.
>
> One problem I will note with this scheme, some Unicode symbols that may be valid D symbol starters may NOT have an upper/lower case, making it impossible to use those as properties.  But I admit having an English bias so I don't see this as a large problem.  Besides, "set" is already English.
>
"natural language inspiration" ... hmm .. where have I seen this? oh right, let's make a DOBOL.

> Note, I've been doing a lot of Objective C lately, and I kind of like the property scheme there (this is quite similar).
>
> Sound crazy?  Ridiculous?  Impossible?  Insulting?
>
> What do you think?
>
> -Steve
more like all four combined.

Not awful... but what about opDispatch setters?

Perhaps we could do it this way:


void opSet(string variable, T)(T value) {}


Foo foo;
foo.s = 10; // if s doesn't exist, do opSet!"s"(10)


If you only want a setter for one particular name

void opSet(string name : "s")(int val) {}



It'd solve the unicode thing too, though at the cost of a little more verboseness for some things.



Oh crap what if it needs to be virtual. Blargh. I'll throw it out anyway.

On 01/29/2013 06:16 PM, Adam D. Ruppe wrote:
> Not awful... but what about opDispatch setters?
>
> Perhaps we could do it this way:
>
>
> void opSet(string variable, T)(T value) {}
>...
> Oh crap what if it needs to be virtual. Blargh. I'll throw it out anyway.

private int _s;
protected void setS(int value){ this._s=value; }
template opSet(string variable : "s")(int value){ alias opSet = setS; }

On 2013-01-29 18:10, Steven Schveighoffer wrote:
> If there is no y field, then then the compiler ALSO tries:
> x.setY(...);
>                      [...]
> One problem I will note with this scheme, some Unicode symbols that may be valid
> D symbol starters may NOT have an upper/lower case, making it impossible to use
> those as properties.  But I admit having an English bias so I don't see this as
> a large problem.  Besides, "set" is already English.

It's inconceivable why on earth would you call this a "compromise". :)

On Tuesday, 29 January 2013 at 17:21:31 UTC, Timon Gehr wrote:
> template opSet(string variable : "s")(int value){ alias opSet = setS; }

ah yes, outstanding. So that's workable.

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.

And if we want it to work to be able to swap a variable for a property function (which is one of the purposes of properties in the first place), not only do we need to improve the property rewriting (which could be done with your scheme), but we'd need to be able to mark a variable in such a way that it couldn't be used for anything which wouldn't work with a property function (e.g. taking its address would have to be illegal), and for that, you'd need an explicit attribute such as @property.

So, if we want to be able to swap between variables and property functions during refactoring or design changes or whatnot (as properties are supposed to allow), we're going to need explicit properties of some kind. That could be done with getProp and setProp instead of @property if we really wanted to, but we'd still need a way to mark variables, and for that, you'd probably need an actual attribute like @property.

If we go any route other than explicit properties, we're giving up on the possibility of being able to swap variables and property functions without breaking code.

- Jonathan M Davis

On Tuesday, 29 January 2013 at 23:09:55 UTC, Jonathan M Davis wrote:
[..]
>
> If we go any route other than explicit properties, we're giving up on the
> possibility of being able to swap variables and property functions without
> breaking code.
>
> - Jonathan M Davis

Given how D currently works, I don't see how we can realistically implement a function as a drop in replacement for a variable and expect code to continue working as if nothing had changed.

One of the bigger problems is that the getter returns by value, not ref, so everything that expects a ref return will fail.

I expect to make precise variable emulation through properties will require a lot of compiler magic, and there will be inevitable bugs and conflicts that follow. I really don't see that there's enough value with the property concept to justify the costs of precise variable emulation.

You know a lot more about implementing compiler magic than I do, so I'll ask you if you think the effort is doable enough to justify having property functions that can act like a drop in replacement for existing variables?

--rt

On Wednesday, January 30, 2013 00:55:13 Rob T wrote:
> On Tuesday, 29 January 2013 at 23:09:55 UTC, Jonathan M Davis
> wrote:
> [..]
> 
> > If we go any route other than explicit properties, we're giving
> > up on the
> > possibility of being able to swap variables and property
> > functions without
> > breaking code.
> > 
> > - Jonathan M Davis
> 
> Given how D currently works, I don't see how we can realistically implement a function as a drop in replacement for a variable and expect code to continue working as if nothing had changed.
> 
> One of the bigger problems is that the getter returns by value, not ref, so everything that expects a ref return will fail.
> 
> I expect to make precise variable emulation through properties will require a lot of compiler magic, and there will be inevitable bugs and conflicts that follow. I really don't see that there's enough value with the property concept to justify the costs of precise variable emulation.
> 
> You know a lot more about implementing compiler magic than I do, so I'll ask you if you think the effort is doable enough to justify having property functions that can act like a drop in replacement for existing variables?

I believe that two main things are needed:

1. Make it possible to mark a variable such that you can't do anything with it that you couldn't do with a property function (e.g. taking its address needs to be illegal).

2. Add property rewrites to make it so that stuff like ++ and += work.

You'll never get a property function to operate 100% like a variable, but you _can_ make it so that it's very close.. C# gets away with making variables and property functions swappable because it do stuff like let you take the address of a variable or a function. We basically need to do the same by restricting variables which are properties and improving the rewrites that the compile does for property functions.

- Jonathan M Davis

It deeply disturbs me that people even take the original post seriously.