www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - YAPP - yet another properties poll

reply aarti_pl <aarti interia.pl> writes:
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

----------------
Jul 31 2009
next sibling parent reply Jesse Phillips <jessekphillips+d gmail.com> writes:
aarti_pl Wrote:

 Please notice that only one option should be chosen.
But the multiple options allow for better proportional representation in the poll. http://bcn.boulder.co.us/government/approvalvote/altvote.html Really I don't know why polling/voting systems aren't setup for this stuff.
Jul 31 2009
parent aarti_pl <aarti interia.pl> writes:
Jesse Phillips pisze:
 aarti_pl Wrote:
 
 Please notice that only one option should be chosen.
But the multiple options allow for better proportional representation in the poll.
My point of view was that it will be easier to interpret results. And also the result will be only one (one final implementation), so it would be better to choose only one option. ... And finally I don't know if my php script can support multiple choices... :-) BR Marcin Kuszczak (aarti_pl)
Jul 31 2009
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
aarti_pl wrote:
 Please add another syntax proposals (max. 2 best proposals - with 
 example code) and correct mistakes in questions (if any):
int size { get { return _size; } set { _size = value; } } get, set and value are only "keywords" within a property block, if you use them elsewhere, they're just regular identifiers.
Jul 31 2009
parent aarti_pl <aarti interia.pl> writes:
Robert Fraser pisze:
 aarti_pl wrote:
 Please add another syntax proposals (max. 2 best proposals - with 
 example code) and correct mistakes in questions (if any):
int size { get { return _size; } set { _size = value; } } get, set and value are only "keywords" within a property block, if you use them elsewhere, they're just regular identifiers.
Great! I will add this syntax to the poll. BR Marcin Kuszczak (aarti_pl)
Jul 31 2009
prev sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
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.
Jul 31 2009
parent reply aarti_pl <aarti interia.pl> writes:
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)
Aug 01 2009
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
aarti_pl wrote:
 [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.
Just wanted to point out that yes, it does make sense. I don't agree with it, but it makes sense. Once properties are added the omissible parens can maybe save some typing on function calls, or whatever their advantages are (to be honest I forget why they are useful). It would be impossible to define a function and property of the same name, so no ambiguities would arise.
Aug 01 2009