YAPP - yet another properties poll

[aarti_pl]

Chad J pisze:
> 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.

I think that polls are only useful to get information about user 
preferences, not to solve complicated technical problems. Anyway I 
prefer solving problems "from general to detail". After pool we will 
know what are preferences about most visible part of this problem: 
syntax. Then it will be possible to go deeper into problem.

(I assume here that presented syntaxes don't have grave problems, so 
they are equal in terms of technical solution.)

> "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.

Correct me if I am wrong, but I believe that Walter point of view is 
that problems with current properties can be solved just with some 
adjustments to current syntax?

Anyway I am open for suggestions how this option should be formulated.

> 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.

These are very true comments, but we can't do much about level of 
understanding among voters. That's why questions in poll should be easy 
to understand, so answer is possible without much pre-knowledge.

> 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.

I like you proposed poll (and probably future polls should be more like 
above), but I think I will leave it as it is for now. Below my rationale:

[1] I think this point needs some more description for pool (too 
difficult for uneducated voter to answer).
[2],[3],[4] Choosing one of possible options will give you answer what 
is preferred. Also introducing new syntax without removing ommitable 
parenthesis feature doesn't make much sense, as it cause than there is 
no real difference between function and property.
[5] Let's leave it for another pool :-) Maybe also too technical for pool.
[6] It's also possible to get this information from proposed questions. 
(Not as clear - I agree)

I would like to repeat: I really like your questions - they are simple 
and clear - when making pools it is the must.

I adjusted questions, so they look currently as below:

* Introduce syntax 1 (also remove ommitable parenthesis feature)
* Introduce syntax 2 (also remove ommitable parenthesis feature)
* Introduce syntax 3 (also remove ommitable parenthesis feature)
* Remove ommitable parenthesis feature, not introducing new syntax
* Keep things as they are, resolving existing problems (+=) not
   introducing new syntax
* Keep things as they are now

Thanks for suggestions!

BR
Marcin Kuszczak
(aarti_pl)