YAPP - yet another properties poll

[Chad J]

aarti_pl wrote:
> I put simple script for making pools on my www server.
> 
> It is already working but I would like to get some feedback for
> questions before I post link.
> 
> Please add another syntax proposals (max. 2 best proposals - with
> example code) and correct mistakes in questions (if any):
> 
> (Questions are mostly based on Jesse Phillips questions; I just
> simplified them a little bit and added two syntaxes.)
> 
> Please notice that only one option should be chosen.
> 
> PLEASE DON'T VOTE ON NG! IT WILL BE MUCH MORE CONVENIENT TO USE COMPUTER
> FOR COUNTING VOTES :-) BELOW QUESTIONS ARE JUST TO GET COMMENTS! I WANT
> TO POST LINK TO POLL TOMORROW AFTER GETTING SOME FEEDBACK.
> 
> BR
> Marcin Kuszczak
> (aarti_pl)
> 
> -----------------------
> 
> Poll - Properties for D
> 
> int _size;
> 
> -------------------- Syntax 1 --------------------
> 
> property {
>   int size() {return _size;}
>   void size(int s) {_size = s;}
> }
> 
> -------------------- Syntax 2 --------------------
> 
>   int opGet_size() {return _size;}
>   opSet_size(int s) {_size = s;}
> 
> --------------------------------------------------
> 
> 
> D properties -
> 
> What would you like to see happened?
> 
> * Introduce syntax 1
> * Introduce syntax 2
> * Introduce syntax 3 (??)
> * Keep things as they are, resolving existing problems (+=) without
> involving new property syntax
> * Keep things as they are
> * Remove current property syntax
> 
> ----------------

<rambling and reasoning>

Here are my thoughts:

There is no mention of how the property implementation actually
generates code.  This is important, because the current implementation
is syntax sugar, while my ideal is to have the compiler generate
temporary values to ensure the property always works as expected.  It is
possible to have explicit property syntax yet not do this.

"Keep things as they are, resolving existing problems (+=) without
involving new property syntax"
Is that even logically possible?
The author of this viewpoint should at least point out how this can
actually be done.

I'm glad this moved away from some loosely related question like "what
do you believe this means?" to the more important "what do you want?".

It troubles me that anyone wanting to learn about this issue has to read
through gigantic amounts of newsgroup discussion to be informed.  The
wiki's contents on this subject are somewhat inadequate.  I still feel
that some people who weren't involved in the lengthy discussions are
somewhat uninformed, and it shows in the posts.  This is too bad, since
this voting should ideally hammer out differences in opinion rather than
differences in commitment to newsgroup reading.

At some point I'd like to compile all of the information I've learned
about properties.  It can then be reviewed/amended/corrected to
represent known viewpoints.  It's probably something I could pull off by
the end of the weekend, though it would be an uncomfortable deadline.

Also note that things like the rvalue.member problem and omissible
parentheses feature are orthogonal to properties.  Yes, the omissible
parentheses were added so as to behave like properties, but they are not
the same thing as the "explicit" properties people talk about.  It is
entirely possible to maintain the current omissible parentheses while
implementing an explicit property feature.

</rambling and reasoning>

Thus the options are not entirely exclusive to each other, rather they
form a number of opinions.
In conclusion, I suggest another format for voting:

[1] Should D's rvalue.member syntax be forbidden?
- yes
- no
- only assignment is forbidden, ex: "rvalue.member = foo;"

[2] Should the omissible parentheses feature be removed?
- yes
- no

[3] Should properties have an explicit syntax?
- yes
- no

[4]
(Only vote if you said yes to [3].)
Which syntax do you prefer?
- <syntax a>
- <syntax b>
- <syntax c>
- etc...

[5] Should the compiler to insert extra assignments and temporaries as
needed to ensure setters are called when they appear on the
left-hand-side of assignment expressions and next to unary operators?
(Ex: "a.b.c = 3;" or "widget.rect.w = 100;" )
(Ex: "a.b++;" or "array.length++;" )
- Yes
- No

[6] Do you want existing property-related problems (such as
"array.length++;") to be solved?
- Yes
- No

Voting on any given issue is optional.  For example: it is OK to vote on
[1], [3], and [4], but not on [2], [5], and [6].

My objective in the above was to capture as many viewpoints that I've
witnessed as possible.  I may have missed some, which would be a shame,
but is also almost inevitable.  [6] is somewhat optional, but
potentially enlightening when compared to the others.