www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Function calls

reply bearophile <bearophileHUGS lycos.com> writes:
I have written the following closure, to generate numbers in 1-7 from numbers
in 1-5, as alternative implementation of this:
http://rosettacode.org/wiki/Seven-dice_from_Five-dice#D

auto dice7Gen(alias d5)() {
    int rem = 0;
    int max = 1;

    int gen7() {
        while (rem / 7 == max / 7) {
            while (max < 7) {
                int rand5 = d5() - 1;
                max *= 5;
                rem = 5 * rem + rand5;
            }

            int groups = max / 7;
            if (rem >=  7 * groups) {
                rem -= 7 * groups;
                max -= 7 * groups;
            }
        }

        int result = rem % 7;
        rem /= 7;
        max /= 7;
        return result + 1;
    }

    return gen7;
}

Can you spot the bug? It returns an integer instead of a closure :-)
The correct last line has to be:
    return &gen7;

But I think the real "bug" here is in the D2 design. In D2 calling callables
without () has to be disallowed:
- & to take their reference/address
- () to call them
Otherwise syntax error at compile-time.

Only properties marked with  property are allowed to be called without (). (If
you really want it, then even free functions may be allowed to be marked with
 property. This probably will not cause many bugs).

This can avoid bugs and tidy the language a little more.

Bye,
bearophile
Jan 26 2010
next sibling parent Bernard Helyer <b.helyer gmail.com> writes:
On 27/01/10 20:34, bearophile wrote:
 But I think the real "bug" here is in the D2 design. In D2 calling callables
without () has to be disallowed:
 -&  to take their reference/address
 - () to call them
 Otherwise syntax error at compile-time.
Nothing to add except a voice of support.
Jan 27 2010
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
bearophile wrote:
 I have written the following closure, to generate numbers in 1-7 from numbers
in 1-5, as alternative implementation of this:
 http://rosettacode.org/wiki/Seven-dice_from_Five-dice#D
 
 auto dice7Gen(alias d5)() {
     int rem = 0;
     int max = 1;
 
     int gen7() {
         while (rem / 7 == max / 7) {
             while (max < 7) {
                 int rand5 = d5() - 1;
                 max *= 5;
                 rem = 5 * rem + rand5;
             }
 
             int groups = max / 7;
             if (rem >=  7 * groups) {
                 rem -= 7 * groups;
                 max -= 7 * groups;
             }
         }
 
         int result = rem % 7;
         rem /= 7;
         max /= 7;
         return result + 1;
     }
 
     return gen7;
 }
 
 Can you spot the bug? It returns an integer instead of a closure :-)
 The correct last line has to be:
     return &gen7;
 
 But I think the real "bug" here is in the D2 design. In D2 calling callables
without () has to be disallowed:
 - & to take their reference/address
 - () to call them
 Otherwise syntax error at compile-time.
 
 Only properties marked with  property are allowed to be called without (). (If
you really want it, then even free functions may be allowed to be marked with
 property. This probably will not cause many bugs).
 
 This can avoid bugs and tidy the language a little more.
 
 Bye,
 bearophile
I thought that this issue had been settled a long time ago, and that this was the whole point of property. -Lars
Jan 27 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-27 05:58:51 -0500, "Lars T. Kyllingstad" 
<public kyllingen.NOSPAMnet> said:

 I thought that this issue had been settled a long time ago, and that 
 this was the whole point of  property.
It's just not fully implemented yet. The property attribute is there, but it doesn't change how you can call a function. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 27 2010
prev sibling next sibling parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/27/2010 08:34 AM, bearophile wrote:
 I have written the following closure, to generate numbers in 1-7 from numbers
in 1-5, as alternative implementation of this:
 http://rosettacode.org/wiki/Seven-dice_from_Five-dice#D

 auto dice7Gen(alias d5)() {
      int rem = 0;
      int max = 1;

      int gen7() {
          while (rem / 7 == max / 7) {
              while (max<  7) {
                  int rand5 = d5() - 1;
                  max *= 5;
                  rem = 5 * rem + rand5;
              }

              int groups = max / 7;
              if (rem>=  7 * groups) {
                  rem -= 7 * groups;
                  max -= 7 * groups;
              }
          }

          int result = rem % 7;
          rem /= 7;
          max /= 7;
          return result + 1;
      }

      return gen7;
 }

 Can you spot the bug? It returns an integer instead of a closure :-)
 The correct last line has to be:
      return&gen7;

 But I think the real "bug" here is in the D2 design. In D2 calling callables
without () has to be disallowed:
 -&  to take their reference/address
 - () to call them
 Otherwise syntax error at compile-time.

 Only properties marked with  property are allowed to be called without (). (If
you really want it, then even free functions may be allowed to be marked with
 property. This probably will not cause many bugs).

 This can avoid bugs and tidy the language a little more.

 Bye,
 bearophile
I disagree, I find the function calls without the () to be really prettifying. But maybe that's just me. I don't think that it causes serious bugs, you would see that it's an integer the moment you try and use it. It also helps changing code from/to functions. I really like this feature, and would miss it should it go away.
Jan 27 2010
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle Månsson wrote:
 I disagree, I find the function calls without the () to be really 
 prettifying.
 
 But maybe that's just me.
 
 I don't think that it causes serious bugs, you would see that it's an 
 integer the moment you try and use it. It also helps changing code 
 from/to functions.
 
 I really like this feature, and would miss it should it go away.
Me too. -- Adam D. Ruppe http://arsdnet.net
Jan 27 2010
parent reply downs <default_357-line yahoo.de> writes:
Adam D. Ruppe wrote:
 On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle Månsson wrote:
 I disagree, I find the function calls without the () to be really 
 prettifying.

 But maybe that's just me.

 I don't think that it causes serious bugs, you would see that it's an 
 integer the moment you try and use it. It also helps changing code 
 from/to functions.

 I really like this feature, and would miss it should it go away.
Me too.
Me three.
Jan 27 2010
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-27 14:01:56 -0500, downs <default_357-line yahoo.de> said:

 Adam D. Ruppe wrote:
 On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle Månsson wrote:
 I really like this feature, and would miss it should it go away.
Me too.
Me three.
I'll miss the feature too. But I think it's the right thing to do because otherwise you can't have properties that behave like properties when returning a callable type. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 27 2010
parent reply boscop <kingboscop nospam.gmail.com> writes:
On 27.01.2010 20:54, Michel Fortin wrote:
 On 2010-01-27 14:01:56 -0500, downs <default_357-line yahoo.de> said:
 
 Adam D. Ruppe wrote:
 On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle Månsson wrote:
 I really like this feature, and would miss it should it go away.
Me too.
Me three.
I'll miss the feature too. But I think it's the right thing to do because otherwise you can't have properties that behave like properties when returning a callable type.
It may be optically pleasant sometimes to be able to omit the parens, but beside the problem with returning a callable type it's also easier to spot where computations happen instead of fast access to properties, even more in complex expressions. Of course you can hide a bottleneck in a property but I'm talking about the normal case here. And it's not hard to type two parens for better readability.
Jan 27 2010
parent =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/27/2010 09:53 PM, boscop wrote:
 On 27.01.2010 20:54, Michel Fortin wrote:
 On 2010-01-27 14:01:56 -0500, downs<default_357-line yahoo.de>  said:

 Adam D. Ruppe wrote:
 On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle M�nsson wrote:
 I really like this feature, and would miss it should it go away.
Me too.
Me three.
I'll miss the feature too. But I think it's the right thing to do because otherwise you can't have properties that behave like properties when returning a callable type.
It may be optically pleasant sometimes to be able to omit the parens, but beside the problem with returning a callable type it's also easier to spot where computations happen instead of fast access to properties, even more in complex expressions. Of course you can hide a bottleneck in a property but I'm talking about the normal case here. And it's not hard to type two parens for better readability.
I think you're looking for a profiler. I also disagree about the readability part, I dislike line noise.
Jan 27 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"downs" <default_357-line yahoo.de> wrote in message 
news:hjq2l1$1s5j$1 digitalmars.com...
 Adam D. Ruppe wrote:
 On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle Månsson wrote:
 I disagree, I find the function calls without the () to be really
 prettifying.

 But maybe that's just me.

 I don't think that it causes serious bugs, you would see that it's an
 integer the moment you try and use it. It also helps changing code
 from/to functions.

 I really like this feature, and would miss it should it go away.
Me too.
Me three.
Meh, I hate it hate it hate it hate it hate it. I'd dance on the feature's grave. So I guess you could say I wouldn't miss it. ;)
Jan 27 2010
parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 27 Jan 2010 23:50:26 +0300, Nick Sabalausky <a a.a> wrote:

 "downs" <default_357-line yahoo.de> wrote in message
 news:hjq2l1$1s5j$1 digitalmars.com...
 Adam D. Ruppe wrote:
 On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle M=C3=A5nsson wrote:
 I disagree, I find the function calls without the () to be really
 prettifying.

 But maybe that's just me.

 I don't think that it causes serious bugs, you would see that it's =
an
 integer the moment you try and use it. It also helps changing code
 from/to functions.

 I really like this feature, and would miss it should it go away.
Me too.
Me three.
Meh, I hate it hate it hate it hate it hate it. I'd dance on the =
 feature's
 grave.

 So I guess you could say I wouldn't miss it. ;)
Me too!
Jan 27 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
downs wrote:
 Adam D. Ruppe wrote:
 On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle Månsson wrote:
 I disagree, I find the function calls without the () to be really 
 prettifying.

 But maybe that's just me.

 I don't think that it causes serious bugs, you would see that it's an 
 integer the moment you try and use it. It also helps changing code 
 from/to functions.

 I really like this feature, and would miss it should it go away.
Me too.
Me three.
There was a long discussion about that, which prompted the addition of property. I was in the anti- property camp, but had understanding and sympathy for the ambiguity issues involved without property. There was a vote in which as far as I recall the pro- property camp was beaten to a tender pulp. Now property is in. That has created (as I had anticipated) the unresolved issue of choosing between property or just function for any given parameterless function. Also I need to litter my code with property. To this day I am not sure whether we made the right decision. Andrei
Jan 27 2010
next sibling parent =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/27/2010 09:54 PM, Andrei Alexandrescu wrote:
 downs wrote:
 Adam D. Ruppe wrote:
 On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle M�nsson wrote:
 I disagree, I find the function calls without the () to be really
 prettifying.

 But maybe that's just me.

 I don't think that it causes serious bugs, you would see that it's
 an integer the moment you try and use it. It also helps changing
 code from/to functions.

 I really like this feature, and would miss it should it go away.
Me too.
Me three.
There was a long discussion about that, which prompted the addition of property. I was in the anti- property camp, but had understanding and sympathy for the ambiguity issues involved without property. There was a vote in which as far as I recall the pro- property camp was beaten to a tender pulp. Now property is in. That has created (as I had anticipated) the unresolved issue of choosing between property or just function for any given parameterless function. Also I need to litter my code with property. To this day I am not sure whether we made the right decision. Andrei
Not just parameterless functions, but functions operating on arrays as well. And mostly anything, if I recall correctly.
Jan 27 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-27 15:54:42 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Now  property is in. That has created (as I had anticipated) the 
 unresolved issue of choosing between  property or just function for any 
 given parameterless function. Also I need to litter my code with 
  property. To this day I am not sure whether we made the right decision.
Well, perhaps it'd be better if it was 'property' instead of ' property'. I find the distinction between keywords and attributes to be pretty arbitrary, almost illogical. I'm on the side that attributes (those keywords starting with ) should be reserved to things you can ignore entirely without preventing the program from working. For instance, remove all safe and trusted attributes from a program and it still works with no change in behaviour (except for when an error occurs). 'nothrow', 'pure', 'final', 'deprecated' should be attributes; ' property' should be a regular keyword. Protection attributes could be made attributes too since if you remove them all everything still works. So I think attributes should be reserved to non-essential but useful stuff in the language, generally those things adding restrictions without changing the semantics. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 27 2010
next sibling parent "Craig Black" <craigblack2 cox.net> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:hjqdca$2neo$1 digitalmars.com...
 On 2010-01-27 15:54:42 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:

 Now  property is in. That has created (as I had anticipated) the 
 unresolved issue of choosing between  property or just function for any 
 given parameterless function. Also I need to litter my code with 
  property. To this day I am not sure whether we made the right decision.
Well, perhaps it'd be better if it was 'property' instead of ' property'. I find the distinction between keywords and attributes to be pretty arbitrary, almost illogical. I'm on the side that attributes (those keywords starting with ) should be reserved to things you can ignore entirely without preventing the program from working. For instance, remove all safe and trusted attributes from a program and it still works with no change in behaviour (except for when an error occurs). 'nothrow', 'pure', 'final', 'deprecated' should be attributes; ' property' should be a regular keyword. Protection attributes could be made attributes too since if you remove them all everything still works. So I think attributes should be reserved to non-essential but useful stuff in the language, generally those things adding restrictions without changing the semantics.
Yes, agreed, there should be some more thought put into how keywords work so that things are consistent and make sense. It seems strange that new keywords are preceded by , but older ones are not. However, aesthetically, I prefer the to a double underscore. Perhaps __gshared could be gshared or even shared. -Craig -Craig
Jan 27 2010
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Michel Fortin wrote:
 On 2010-01-27 15:54:42 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 Now  property is in. That has created (as I had anticipated) the 
 unresolved issue of choosing between  property or just function for 
 any given parameterless function. Also I need to litter my code with 
  property. To this day I am not sure whether we made the right decision.
Well, perhaps it'd be better if it was 'property' instead of ' property'. I find the distinction between keywords and attributes to be pretty arbitrary, almost illogical. I'm on the side that attributes (those keywords starting with ) should be reserved to things you can ignore entirely without preventing the program from working. For instance, remove all safe and trusted attributes from a program and it still works with no change in behaviour (except for when an error occurs). 'nothrow', 'pure', 'final', 'deprecated' should be attributes; ' property' should be a regular keyword. Protection attributes could be made attributes too since if you remove them all everything still works. So I think attributes should be reserved to non-essential but useful stuff in the language, generally those things adding restrictions without changing the semantics.
This was actually discussed before, and I think the general conclusion was that there is no useful definition of attributes that includes property. I think I have an idea quite similar to yours, only slightly more specific. I'll post it in a new thread. -Lars
Jan 28 2010
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 27 Jan 2010 15:54:42 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 downs wrote:
 Adam D. Ruppe wrote:
 On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle MÃ¥nsson wrote:
 I disagree, I find the function calls without the () to be really  
 prettifying.

 But maybe that's just me.

 I don't think that it causes serious bugs, you would see that it's an  
 integer the moment you try and use it. It also helps changing code  
 from/to functions.

 I really like this feature, and would miss it should it go away.
Me too.
Me three.
There was a long discussion about that, which prompted the addition of property. I was in the anti- property camp, but had understanding and sympathy for the ambiguity issues involved without property. There was a vote in which as far as I recall the pro- property camp was beaten to a tender pulp. Now property is in. That has created (as I had anticipated) the unresolved issue of choosing between property or just function for any given parameterless function. Also I need to litter my code with property. To this day I am not sure whether we made the right decision.
1. Choosing between including property or not is rare. Most cases are obvious. If you worked with a language that requires property notation 2. Defining property on functions you wish to call as properties can be done all at once, enclosing all properties in a property { } block. No need to "litter" all your code with that. Furthermore, function signature 'documentation' is not as littering as you think. Verbosity at definition is not as cumbersome as verbosity at the call site. In other words, the extra litter at definition time pays huge dividends in clarity at the call site, and is not a constant annoyance (you only define things once). I'm sure C developers who were used to omitting prototypes were equally miffed when it became required. -Steve
Jan 28 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 1. Choosing between including  property or not is rare.  Most cases are 
 obvious.  If you worked with a language that requires property notation 

I need to put it for all front() and empty() declarations. By the way I decided that popFront() is not a property. I don't know why.
 2. Defining  property on functions you wish to call as properties can be 
 done all at once, enclosing all properties in a  property { } block.  No 
 need to "litter" all your code with that.  Furthermore, function 
 signature 'documentation' is not as littering as you think.  Verbosity 
 at definition is not as cumbersome as verbosity at the call site.  In 
 other words, the extra litter at definition time pays huge dividends in 
 clarity at the call site, and is not a constant annoyance (you only 
 define things once).
OK. The problem is, I was already enjoying clarity at the call site. So for me the whole property thing has a much less appeal than it might. I do appreciate that property eliminates ambiguities in corner cases.
 I'm sure C developers who were used to omitting prototypes were equally 
 miffed when it became required.
That situation is different. There's only one possible prototype a function can have. With property, it's anyone's guess. Andrei
Jan 28 2010
next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 1. Choosing between including  property or not is rare.  Most cases 
 are obvious.  If you worked with a language that requires property 

I need to put it for all front() and empty() declarations. By the way I decided that popFront() is not a property. I don't know why.
Because it's an action, not a property. Simple as that. :) Actually, the functions you mention are probably the best examples of why the property attribute is so cool. Using it, you can signify that empty tests for emptiness, and doesn't empty() the range or container. Rule of thumb: noun or adjective --> property verb --> not property -Lars -Lars
Jan 28 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 28 Jan 2010 08:57:15 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 1. Choosing between including  property or not is rare.  Most cases are  
 obvious.  If you worked with a language that requires property notation  

I need to put it for all front() and empty() declarations. By the way I decided that popFront() is not a property. I don't know why.
Because popFront isn't a property. It doesn't return anything, does it? A property either fetches a value or sets a value. Defining anything else as a property is disingenuous, and that was the original problem -- you could make it look like you were accessing a property when you really aren't. popFront should not be a property and should always have parentheses after it.
 2. Defining  property on functions you wish to call as properties can  
 be done all at once, enclosing all properties in a  property { }  
 block.  No need to "litter" all your code with that.  Furthermore,  
 function signature 'documentation' is not as littering as you think.   
 Verbosity at definition is not as cumbersome as verbosity at the call  
 site.  In other words, the extra litter at definition time pays huge  
 dividends in clarity at the call site, and is not a constant annoyance  
 (you only define things once).
OK. The problem is, I was already enjoying clarity at the call site. So for me the whole property thing has a much less appeal than it might. I do appreciate that property eliminates ambiguities in corner cases.
You are governed by your personal restrictions and taste. The problem is that left to their own devices, people will use their own style of calling functions. Some will always use parentheses even when the function is supposed to be a property, others will always avoid parentheses when they can, yet others will be somewhere in between. The end result is you have code that is not intuitive to you if the author doesn't follow your style. At least with a property requirement, there is only one style.
 I'm sure C developers who were used to omitting prototypes were equally  
 miffed when it became required.
That situation is different. There's only one possible prototype a function can have. With property, it's anyone's guess.
the similarity is that an optional specification became required because it was confusing when you went to use the function how to call it. I agree the similarity is not 1 to 1, but what I meant to point out is that people who started with ANSI C (myself included) never missed that feature. Only those who used the feature would be upset. Likewise, I would never miss the optional-parens style of a function that's not a property because I never really got used to doing it. So do you miss it because it had true benefits or because you're just used to doing it that way? -Steve
Jan 28 2010
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 28 de enero a las 07:57 me escribiste:
 Steven Schveighoffer wrote:
1. Choosing between including  property or not is rare.  Most
cases are obvious.  If you worked with a language that requires

you.
I need to put it for all front() and empty() declarations. By the way I decided that popFront() is not a property. I don't know why.
Because it denotes an action? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------
Jan 28 2010
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thu, Jan 28, 2010 at 11:47:45AM -0300, Leandro Lucarella wrote:
 Andrei Alexandrescu, el 28 de enero a las 07:57 me escribiste:
 I need to put it for all front() and empty() declarations. By the
 way I decided that popFront() is not a property. I don't know why.
Because it denotes an action?
I don't think it is that simple - I see popFront; as an action all the same as popFront(); I wonder if there is some correlation between old assembly programmers and newer language users on this issue. In assembly, there's no distinction; you write all instructions and many macros without parens, so it is no weird thing. -- Adam D. Ruppe http://arsdnet.net
Jan 28 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 28 Jan 2010 10:22:45 -0500, Adam D. Ruppe  
<destructionator gmail.com> wrote:

 On Thu, Jan 28, 2010 at 11:47:45AM -0300, Leandro Lucarella wrote:
 Andrei Alexandrescu, el 28 de enero a las 07:57 me escribiste:
 I need to put it for all front() and empty() declarations. By the
 way I decided that popFront() is not a property. I don't know why.
Because it denotes an action?
I don't think it is that simple - I see popFront; as an action all the same as popFront();
Whether you use parentheses or not, it's not a property. The statement of Andrei is that he doesn't know why it's not a property. The simple reason is because it's an action. Now, does popFront; look like an action? Yes. But that is not the case being disambiguated. It is collateral damage. Because the compiler doesn't understand English, it can't know whether to disallow popFront; any more than an ambiguous term like read;. If there were a way to enforce "only terms that are clearly denote actions can be called without parentheses," I'd be all for it. -Steve
Jan 28 2010
next sibling parent =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/28/2010 04:28 PM, Steven Schveighoffer wrote:
 On Thu, 28 Jan 2010 10:22:45 -0500, Adam D. Ruppe
 <destructionator gmail.com> wrote:

 On Thu, Jan 28, 2010 at 11:47:45AM -0300, Leandro Lucarella wrote:
 Andrei Alexandrescu, el 28 de enero a las 07:57 me escribiste:
 I need to put it for all front() and empty() declarations. By the
 way I decided that popFront() is not a property. I don't know why.
Because it denotes an action?
I don't think it is that simple - I see popFront; as an action all the same as popFront();
Whether you use parentheses or not, it's not a property. The statement of Andrei is that he doesn't know why it's not a property. The simple reason is because it's an action. Now, does popFront; look like an action? Yes. But that is not the case being disambiguated. It is collateral damage. Because the compiler doesn't understand English, it can't know whether to disallow popFront; any more than an ambiguous term like read;. If there were a way to enforce "only terms that are clearly denote actions can be called without parentheses," I'd be all for it. -Steve
I do not understand why this is damage at all. It's like collateral fluff, not collateral damage. Also, is there any case where a function is not a property and do not denote an action but is still callable without parenthesis? Aside from bad naming, of course.
Jan 28 2010
prev sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Steven Schveighoffer wrote:
 On Thu, 28 Jan 2010 10:22:45 -0500, Adam D. Ruppe 
 <destructionator gmail.com> wrote:
 
 On Thu, Jan 28, 2010 at 11:47:45AM -0300, Leandro Lucarella wrote:
 Andrei Alexandrescu, el 28 de enero a las 07:57 me escribiste:
 I need to put it for all front() and empty() declarations. By the
 way I decided that popFront() is not a property. I don't know why.
Because it denotes an action?
I don't think it is that simple - I see popFront; as an action all the same as popFront();
Whether you use parentheses or not, it's not a property. The statement of Andrei is that he doesn't know why it's not a property. The simple reason is because it's an action. Now, does popFront; look like an action? Yes. But that is not the case being disambiguated. It is collateral damage. Because the compiler doesn't understand English, it can't know whether to disallow popFront; any more than an ambiguous term like read
...or, as in Andrei's example, 'empty'. In Java you'd write isEmpty(), or even worse, getEmpty(). In D we now have the option of declaring it a property, with little chance of people thinking it actually empties anything. -Lars
Jan 28 2010
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 28 Jan 2010 20:28:17 +0300, Lars T. Kyllingstad  
<public kyllingen.nospamnet> wrote:

 Steven Schveighoffer wrote:
 On Thu, 28 Jan 2010 10:22:45 -0500, Adam D. Ruppe  
 <destructionator gmail.com> wrote:

 On Thu, Jan 28, 2010 at 11:47:45AM -0300, Leandro Lucarella wrote:
 Andrei Alexandrescu, el 28 de enero a las 07:57 me escribiste:
 I need to put it for all front() and empty() declarations. By the
 way I decided that popFront() is not a property. I don't know why.
Because it denotes an action?
I don't think it is that simple - I see popFront; as an action all the same as popFront();
Whether you use parentheses or not, it's not a property. The statement of Andrei is that he doesn't know why it's not a property. The simple reason is because it's an action. Now, does popFront; look like an action? Yes. But that is not the case being disambiguated. It is collateral damage. Because the compiler doesn't understand English, it can't know whether to disallow popFront; any more than an ambiguous term like read
...or, as in Andrei's example, 'empty'. In Java you'd write isEmpty(), or even worse, getEmpty(). In D we now have the option of declaring it a property, with little chance of people thinking it actually empties anything. -Lars
Great explanation, very convincing!
Jan 28 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Thu, 28 Jan 2010 20:28:17 +0300, Lars T. Kyllingstad 
 <public kyllingen.nospamnet> wrote:
 
 Steven Schveighoffer wrote:
 On Thu, 28 Jan 2010 10:22:45 -0500, Adam D. Ruppe 
 <destructionator gmail.com> wrote:

 On Thu, Jan 28, 2010 at 11:47:45AM -0300, Leandro Lucarella wrote:
 Andrei Alexandrescu, el 28 de enero a las 07:57 me escribiste:
 I need to put it for all front() and empty() declarations. By the
 way I decided that popFront() is not a property. I don't know why.
Because it denotes an action?
I don't think it is that simple - I see popFront; as an action all the same as popFront();
Whether you use parentheses or not, it's not a property. The statement of Andrei is that he doesn't know why it's not a property. The simple reason is because it's an action. Now, does popFront; look like an action? Yes. But that is not the case being disambiguated. It is collateral damage. Because the compiler doesn't understand English, it can't know whether to disallow popFront; any more than an ambiguous term like read
...or, as in Andrei's example, 'empty'. In Java you'd write isEmpty(), or even worse, getEmpty(). In D we now have the option of declaring it a property, with little chance of people thinking it actually empties anything. -Lars
Great explanation, very convincing!
How about this: foreach (line; stdin.byLine()) { ... } vs. foreach (line; stdin.byLine) { ... } How do I choose? Andrei
Jan 28 2010
next sibling parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/28/2010 09:59 PM, Andrei Alexandrescu wrote:
 Denis Koroskin wrote:
 On Thu, 28 Jan 2010 20:28:17 +0300, Lars T. Kyllingstad
 <public kyllingen.nospamnet> wrote:

 Steven Schveighoffer wrote:
 On Thu, 28 Jan 2010 10:22:45 -0500, Adam D. Ruppe
 <destructionator gmail.com> wrote:

 On Thu, Jan 28, 2010 at 11:47:45AM -0300, Leandro Lucarella wrote:
 Andrei Alexandrescu, el 28 de enero a las 07:57 me escribiste:
 I need to put it for all front() and empty() declarations. By the
 way I decided that popFront() is not a property. I don't know why.
Because it denotes an action?
I don't think it is that simple - I see popFront; as an action all the same as popFront();
Whether you use parentheses or not, it's not a property. The statement of Andrei is that he doesn't know why it's not a property. The simple reason is because it's an action. Now, does popFront; look like an action? Yes. But that is not the case being disambiguated. It is collateral damage. Because the compiler doesn't understand English, it can't know whether to disallow popFront; any more than an ambiguous term like read
...or, as in Andrei's example, 'empty'. In Java you'd write isEmpty(), or even worse, getEmpty(). In D we now have the option of declaring it a property, with little chance of people thinking it actually empties anything. -Lars
Great explanation, very convincing!
How about this: foreach (line; stdin.byLine()) { ... } vs. foreach (line; stdin.byLine) { ... } How do I choose? Andrei
I say you don't, it works both ways as it is now. I say, let's not remove this feature :) property should be for when you need to assign to it. Maybe.
Jan 28 2010
parent reply Don <nospam nospam.com> writes:
Pelle MÃ¥nsson wrote:
 On 01/28/2010 09:59 PM, Andrei Alexandrescu wrote:
 Denis Koroskin wrote:
 On Thu, 28 Jan 2010 20:28:17 +0300, Lars T. Kyllingstad
 <public kyllingen.nospamnet> wrote:

 Steven Schveighoffer wrote:
 On Thu, 28 Jan 2010 10:22:45 -0500, Adam D. Ruppe
 <destructionator gmail.com> wrote:

 On Thu, Jan 28, 2010 at 11:47:45AM -0300, Leandro Lucarella wrote:
 Andrei Alexandrescu, el 28 de enero a las 07:57 me escribiste:
 I need to put it for all front() and empty() declarations. By the
 way I decided that popFront() is not a property. I don't know why.
Because it denotes an action?
I don't think it is that simple - I see popFront; as an action all the same as popFront();
Whether you use parentheses or not, it's not a property. The statement of Andrei is that he doesn't know why it's not a property. The simple reason is because it's an action. Now, does popFront; look like an action? Yes. But that is not the case being disambiguated. It is collateral damage. Because the compiler doesn't understand English, it can't know whether to disallow popFront; any more than an ambiguous term like read
...or, as in Andrei's example, 'empty'. In Java you'd write isEmpty(), or even worse, getEmpty(). In D we now have the option of declaring it a property, with little chance of people thinking it actually empties anything. -Lars
Great explanation, very convincing!
How about this: foreach (line; stdin.byLine()) { ... } vs. foreach (line; stdin.byLine) { ... } How do I choose? Andrei
I say you don't, it works both ways as it is now. I say, let's not remove this feature :) property should be for when you need to assign to it. Maybe.
I think there are 3 cases: (1) I want this to _always_ be treated as if it were a field; (2) I want this to _always_ be treated as a function; (3) I don't care. (this arises most frequently in generic code: you're forced to choose between a field and a function, but you can't have both). D1 caters for case (3) very well, but does extremely poorly for (1) and (2). property is perfect for case (1). It also seems reasonable to disallow property assignment syntax for anything which isn't marked as property. Disallowing removable parentheses for no-parameter functions is the contentious part.
Jan 28 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:
 I think there are 3 cases:
 (1) I want this to _always_ be treated as if it were a field;
 (2) I want this to _always_ be treated as a function;
 (3) I don't care. (this arises most frequently in generic code: you're 
 forced to choose between a field and a function, but you can't have both).
 
 D1 caters for case (3) very well, but does extremely poorly for (1) and 
 (2).
  property is perfect for case (1). It also seems reasonable to disallow 
 property assignment syntax for anything which isn't marked as  property.
 
 Disallowing removable parentheses for no-parameter functions is the 
 contentious part.
Good summary. I now wonder, could one overload based on property? auto a = container.empty; // check for emptiness container.empty(); // take the trash out ! Anyway, I have one more comment about the example: foreach (line; stdio.byLine) { ... } vs. foreach (line; stdio.byLine()) { ... } Steve said, byLine fetches a range off stdio. In fact it's not - it's an opApply() based loop. That already muddies the waters. But I have another, bigger concern. When I think of a property, I think I fetch it and it can't go back and modify its originator. Like if I do: auto x = y.length; I don't expect to later mess with x and change y through it. I'm sure an inventive mind could find an argument against this but if I try to be honest with myself I'd think it's tenuous to have the tail property wag the dog object. Unfortunately that's exactly what happens with stdin.byLine: even if it were a range, it would alter stdin through its usage. It's not a property in the same way stdin.eof or stdin.isOpen are. Andrei
Jan 28 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Andrei Alexandrescu wrote:
 Don wrote:
 I think there are 3 cases:
 (1) I want this to _always_ be treated as if it were a field;
 (2) I want this to _always_ be treated as a function;
 (3) I don't care. (this arises most frequently in generic code: you're 
 forced to choose between a field and a function, but you can't have 
 both).

 D1 caters for case (3) very well, but does extremely poorly for (1) 
 and (2).
  property is perfect for case (1). It also seems reasonable to 
 disallow property assignment syntax for anything which isn't marked as 
  property.

 Disallowing removable parentheses for no-parameter functions is the 
 contentious part.
Good summary. I now wonder, could one overload based on property? auto a = container.empty; // check for emptiness container.empty(); // take the trash out ! Anyway, I have one more comment about the example: foreach (line; stdio.byLine) { ... } vs. foreach (line; stdio.byLine()) { ... } Steve said, byLine fetches a range off stdio. In fact it's not - it's an opApply() based loop.
I was mistaken. byLine does fetch a range. http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/stdio.d BTW I love byLine. Andrei
Jan 28 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:hjt1ea$306u$1 digitalmars.com...
 Good summary. I now wonder, could one overload based on  property?

 auto a = container.empty; // check for emptiness
 container.empty();        // take the trash out

 !
Why would that ever enter into anyone's mind? You already can't overload on a member's type, you already can't overload on function's return type, and you certainly can't overload on a mere decorator. There's no issue here.
 Anyway, I have one more comment about the example:

 foreach (line; stdio.byLine) { ... }
 vs.
 foreach (line; stdio.byLine()) { ... }

 Steve said, byLine fetches a range off stdio. In fact it's not - it's an 
 opApply() based loop. That already muddies the waters. But I have another, 
 bigger concern. When I think of a property, I think I fetch it and it 
 can't go back and modify its originator. Like if I do:

 auto x = y.length;

 I don't expect to later mess with x and change y through it.

 I'm sure an inventive mind could find an argument against this but if I 
 try to be honest with myself I'd think it's tenuous to have the tail 
 property wag the dog object.
If you see a problem with being able to do this: auto dog = new Dog(); auto tail = dog.tail; tail.wag(); Then you obviously haven't done much game programming. (Now obviously something like "tail.bark()" would be ridiculous, but hardly a real risk.) Additionally, even if that could be considered a problem, I don't see how having ommittable parens on no-param function calls would in any way alleviate the problem.
Jan 28 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:hjt1ea$306u$1 digitalmars.com...
 Good summary. I now wonder, could one overload based on  property?

 auto a = container.empty; // check for emptiness
 container.empty();        // take the trash out

 !
Why would that ever enter into anyone's mind? You already can't overload on a member's type, you already can't overload on function's return type, and you certainly can't overload on a mere decorator. There's no issue here.
 Anyway, I have one more comment about the example:

 foreach (line; stdio.byLine) { ... }
 vs.
 foreach (line; stdio.byLine()) { ... }

 Steve said, byLine fetches a range off stdio. In fact it's not - it's an 
 opApply() based loop. That already muddies the waters. But I have another, 
 bigger concern. When I think of a property, I think I fetch it and it 
 can't go back and modify its originator. Like if I do:

 auto x = y.length;

 I don't expect to later mess with x and change y through it.

 I'm sure an inventive mind could find an argument against this but if I 
 try to be honest with myself I'd think it's tenuous to have the tail 
 property wag the dog object.
If you see a problem with being able to do this: auto dog = new Dog(); auto tail = dog.tail; tail.wag();
Nonono, the expression "tail wagging the dog" means that the actual tail stands still and the dog is shaking like a tail. Andrei
Jan 28 2010
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 28 Jan 2010 15:59:30 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:
 On Thu, 28 Jan 2010 20:28:17 +0300, Lars T. Kyllingstad  
 <public kyllingen.nospamnet> wrote:

 Steven Schveighoffer wrote:
 On Thu, 28 Jan 2010 10:22:45 -0500, Adam D. Ruppe  
 <destructionator gmail.com> wrote:

 On Thu, Jan 28, 2010 at 11:47:45AM -0300, Leandro Lucarella wrote:
 Andrei Alexandrescu, el 28 de enero a las 07:57 me escribiste:
 I need to put it for all front() and empty() declarations. By the
 way I decided that popFront() is not a property. I don't know why.
Because it denotes an action?
I don't think it is that simple - I see popFront; as an action all the same as popFront();
Whether you use parentheses or not, it's not a property. The statement of Andrei is that he doesn't know why it's not a property. The simple reason is because it's an action. Now, does popFront; look like an action? Yes. But that is not the case being disambiguated. It is collateral damage. Because the compiler doesn't understand English, it can't know whether to disallow popFront; any more than an ambiguous term like read
...or, as in Andrei's example, 'empty'. In Java you'd write isEmpty(), or even worse, getEmpty(). In D we now have the option of declaring it a property, with little chance of people thinking it actually empties anything. -Lars
Great explanation, very convincing!
How about this: foreach (line; stdin.byLine()) { ... } vs. foreach (line; stdin.byLine) { ... } How do I choose?
byLine is a property. It is fetching a range on stdin. -Steve
Jan 28 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Thu, 28 Jan 2010 15:59:30 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 foreach (line; stdin.byLine()) { ... }

 vs.

 foreach (line; stdin.byLine) { ... }

 How do I choose?
byLine is a property. It is fetching a range on stdin. -Steve
Damn. I was sure the answer will be different. Andrei
Jan 28 2010
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Thu, Jan 28, 2010 at 1:26 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Steven Schveighoffer wrote:
 On Thu, 28 Jan 2010 15:59:30 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 foreach (line; stdin.byLine()) { ... }

 vs.

 foreach (line; stdin.byLine) { ... }

 How do I choose?
byLine is a property. =A0It is fetching a range on stdin. -Steve
Damn. I was sure the answer will be different.
Maybe "property" is a misleading word. Clearly there are more things to which that applies than just what the traditional definition of the word would imply. I would not in English call my nose a "property" of me, but if I were a D object and had a .nose accessor, I would certainly think that accessor would qualify as a D property. How's this: anything that you can "get" without specifying additional information (and which doesn't change the outwardly visible state the use of "get" and "set" perhaps does a better job of conveying this. --bb
Jan 28 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 1:26 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Steven Schveighoffer wrote:
 On Thu, 28 Jan 2010 15:59:30 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 foreach (line; stdin.byLine()) { ... }

 vs.

 foreach (line; stdin.byLine) { ... }

 How do I choose?
byLine is a property. It is fetching a range on stdin. -Steve
Damn. I was sure the answer will be different.
Maybe "property" is a misleading word. Clearly there are more things to which that applies than just what the traditional definition of the word would imply. I would not in English call my nose a "property" of me, but if I were a D object and had a .nose accessor, I would certainly think that accessor would qualify as a D property. How's this: anything that you can "get" without specifying additional information (and which doesn't change the outwardly visible state the use of "get" and "set" perhaps does a better job of conveying this.
This raises the hair on my back. It's back to programming-by-convention. Andrei
Jan 28 2010
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Thu, Jan 28, 2010 at 2:07 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 1:26 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Steven Schveighoffer wrote:
 On Thu, 28 Jan 2010 15:59:30 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 foreach (line; stdin.byLine()) { ... }

 vs.

 foreach (line; stdin.byLine) { ... }

 How do I choose?
byLine is a property. =A0It is fetching a range on stdin. -Steve
Damn. I was sure the answer will be different.
Maybe "property" is a misleading word. =A0Clearly there are more things to which that applies than just what the traditional definition of the word would imply. =A0I would not in English call my nose a "property" of me, but if I were a D object and had a .nose accessor, I would certainly think that accessor would qualify as a D property. How's this: anything that you can "get" without specifying additional information (and which doesn't change the outwardly visible state the use of "get" and "set" perhaps does a better job of conveying this.
This raises the hair on my back. It's back to programming-by-convention.
Wait, you started off by saying "how do I decide?" and we give you a rule you can follow to decide and now you say you don't like it because it's programming-by-convention? I guess I don't really understand what your argument is. --bb
Jan 28 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 2:07 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 1:26 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Steven Schveighoffer wrote:
 On Thu, 28 Jan 2010 15:59:30 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 foreach (line; stdin.byLine()) { ... }

 vs.

 foreach (line; stdin.byLine) { ... }

 How do I choose?
byLine is a property. It is fetching a range on stdin. -Steve
Damn. I was sure the answer will be different.
Maybe "property" is a misleading word. Clearly there are more things to which that applies than just what the traditional definition of the word would imply. I would not in English call my nose a "property" of me, but if I were a D object and had a .nose accessor, I would certainly think that accessor would qualify as a D property. How's this: anything that you can "get" without specifying additional information (and which doesn't change the outwardly visible state the use of "get" and "set" perhaps does a better job of conveying this.
This raises the hair on my back. It's back to programming-by-convention.
Wait, you started off by saying "how do I decide?" and we give you a rule you can follow to decide and now you say you don't like it because it's programming-by-convention? I guess I don't really understand what your argument is.
It's not a rule. It's several contradictory ones. Andrei
Jan 28 2010
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Thu, Jan 28, 2010 at 2:25 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 2:07 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 1:26 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Steven Schveighoffer wrote:
 On Thu, 28 Jan 2010 15:59:30 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 foreach (line; stdin.byLine()) { ... }

 vs.

 foreach (line; stdin.byLine) { ... }

 How do I choose?
byLine is a property. =A0It is fetching a range on stdin. -Steve
Damn. I was sure the answer will be different.
Maybe "property" is a misleading word. =A0Clearly there are more thing=
s
 to which that applies than just what the traditional definition of the
 word would imply. =A0I would not in English call my nose a "property" =
of
 me, but if I were a D object and had a .nose accessor, I would
 certainly think that accessor would qualify as a D property.

 How's this: anything that you can "get" without specifying additional
 information (and which doesn't change the outwardly visible state the

al
 use of "get" and "set" perhaps does a better job of conveying this.
This raises the hair on my back. It's back to programming-by-convention=
.
 Wait, you started off by saying "how do I decide?" and we give you a
 rule you can follow to decide and now you say you don't like it
 because it's programming-by-convention? =A0 I guess I don't really
 understand what your argument is.
It's not a rule. It's several contradictory ones.
Please point out the contradictions. I'm not seeing them. --bb
Jan 28 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 2:25 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 2:07 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 1:26 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Steven Schveighoffer wrote:
 On Thu, 28 Jan 2010 15:59:30 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 foreach (line; stdin.byLine()) { ... }

 vs.

 foreach (line; stdin.byLine) { ... }

 How do I choose?
byLine is a property. It is fetching a range on stdin. -Steve
Damn. I was sure the answer will be different.
Maybe "property" is a misleading word. Clearly there are more things to which that applies than just what the traditional definition of the word would imply. I would not in English call my nose a "property" of me, but if I were a D object and had a .nose accessor, I would certainly think that accessor would qualify as a D property. How's this: anything that you can "get" without specifying additional information (and which doesn't change the outwardly visible state the use of "get" and "set" perhaps does a better job of conveying this.
This raises the hair on my back. It's back to programming-by-convention.
Wait, you started off by saying "how do I decide?" and we give you a rule you can follow to decide and now you say you don't like it because it's programming-by-convention? I guess I don't really understand what your argument is.
It's not a rule. It's several contradictory ones.
Please point out the contradictions. I'm not seeing them.
Some said it should be stdin.byLine(), some others said it should be stdin.byLine. They invoked contradictory rules that led to contradictory conclusions. Andrei
Jan 28 2010
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Thu, Jan 28, 2010 at 2:48 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 2:25 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 2:07 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 1:26 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Steven Schveighoffer wrote:
 On Thu, 28 Jan 2010 15:59:30 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 foreach (line; stdin.byLine()) { ... }

 vs.

 foreach (line; stdin.byLine) { ... }

 How do I choose?
byLine is a property. =A0It is fetching a range on stdin. -Steve
Damn. I was sure the answer will be different.
Maybe "property" is a misleading word. =A0Clearly there are more thi=
ngs
 to which that applies than just what the traditional definition of t=
he
 word would imply. =A0I would not in English call my nose a "property=
" of
 me, but if I were a D object and had a .nose accessor, I would
 certainly think that accessor would qualify as a D property.

 How's this: anything that you can "get" without specifying additiona=
l
 information (and which doesn't change the outwardly visible state th=
e

cial
 use of "get" and "set" perhaps does a better job of conveying this.
This raises the hair on my back. It's back to programming-by-convention.
Wait, you started off by saying "how do I decide?" and we give you a rule you can follow to decide and now you say you don't like it because it's programming-by-convention? =A0 I guess I don't really understand what your argument is.
It's not a rule. It's several contradictory ones.
Please point out the contradictions. =A0I'm not seeing them.
Some said it should be stdin.byLine(), some others said it should be stdin.byLine. They invoked contradictory rules that led to contradictory conclusions.
Ok, I thought you were saying my rule was somehow self-contradictory. I understand what you mean now. Just that the rule to apply is not obvious. But I think that applies to many things in computer programming. Whether to use pointers or references. Whether to use classes or struct. Whether to make something private or protected, or virtual or non-virtual. Some cases are obvious, others are not. --bb
Jan 28 2010
prev sibling parent reply Gerrit Wichert <gw green-stores.de> writes:
Hello,

I think the biggest part of our problem with  property is, that we are
using the wrong words. I'm no native english speaker so it  may be that
i'm totaly wrong with this,  but that's my impression. When i hear the
word property i'm thinking: "ok, this is a well defined part of the
internal state of that object instance that i'm allowed to  interact
with". 

That's what i think a property is. It is not about parentheses or not
parentheses. It is not about just marking functions to change their call
behaviour.

I think a property should be about *first* naming and defining a
distinct part of the object state and thereafter *optionally* defining
how to deal with it.

I really  don't want to talk much about syntax  but  i like the  way 
Moose  has solved this problem for  Perl5.  Even if its syntax is not
compatible to a C derived language language like D (btw. why not?), a
quick skim of its documentation  may be a source of inspiration. It
clearly was for me.

http://search.cpan.org/~drolsky/Moose-0.94/lib/Moose.pm

The coolest thing about Moose is, that it doesn't  change the language
of Perl5 in any way. For attributes (their name for properties) it just
implements  a declarative syntax that is valid perl code and executed at
compile time to define fields and accessor functions.

so a simple
    has 'x' => (is => 'rw', isa => 'Int');
just defines a field that can hold an integer and two accessor functions
x() and x(int). The name of  the  real field and how it is stored is
adjustable but defaults to the way perl objects are normaly constructed.

    has 'x' => (is => 'ro', isa => 'Int');
just omits constructing a write accessor.

To be exact at this a readonly property doesn't mean it is const, it
means that you don't have a write accessor and therefore can't
substitute its content. You can get a mutable subobject or struct via a
read accesseor and manipulate it via its own property accessors but you
can't substitute it since you have no write accessor. If you don't want
to let the client manipulate intenal state via a read accessor of a
complex property just make it return a const subobject.   

Semantically this turns a property into a little sub-class even if it is
not defined as such. It is implemented as old school fields and accessor
functions. But they are auto generated until you feel the need to define
them explicitly. There are much more ideas in Moose that may be
applicable to D that i won't go any deeper in here. Please skim it's 
documentation if you're  interested.  For me it has  turned Perl into
something beautiful while being extremly flexible.

But I don't want to advertise any Perl, just hoping the idees behind
Moose can be helpful. So back to D.

The simplest property definition i can think of ist this:

class c {
    public:
    int a;
}

This can be interpreted as a property with name 'a' that has compiler
generated accessor functions int a(), and a (int) or int a(int) .The
compiler can not only auto generate them, it can also opimize them away.
So at the end of the day a field can be seen as an optimized property.
This implicates that i should be able to access fields using accessor
function syntax.
Yes, i really mean someting like x = c.a() or c.a( x) also for field
access. Even auto old = c.a( x) may be usefull. I think this can be
essential for templates or meta programming.
Syntax like x = c.a or c.a = x is cute but should be rewritten to the
above by the compiler and then optimized away in case of auto-generated
accessors.

The whole talk about using parentheses or not  for accessor functions, 
just to  better distinguish accessors from real fields when reading D
sources i have a really simple solution for. Just conceptually get rid
of real fields  in objects. Then we don't have to distinguish. And if
"int a;" in  a class definition simply defines a lightweight rw property
that internally is implemented by the compiler as a field, we get the
benefits of real properties for each field without changing one line of
already written source code. The danger of confusing field access with a
function call omitting empty parentheses vanishes as well because every
field access is now consequently a call of a property accessor even when
optimized away. So function calls can safely omit empty parentheses
without being ambigious.   

Then later we can think about creating a DSL that helps us to *declare*
more complex  types of properties and have  the compiler construct the
implicit parts at compile time. For instance i can think of a boolean
property that has a toggle accessor.

We shouldn't compose our classes from fields and functions that we
declare to be called with or without parentheses.
We should compose our classes from properties we declare (public, privat
or whatever) and let the compiler do the boring work for us.   


Now to your problem with byLine:


 Some said it should be stdin.byLine(), some others said it should be
stdin.byLine. They invoked contradictory rules that led to contradictory conclusions. If byLine internally constructs a new range instance that happens to use stdin for iterating by line, this to me ist clearly a function. And then the normal rules for calling a function in the D language must apply. This has nothing to do with properties. If you have a single ByLineRange instance stored in stdin that is simply handed out by the byLine function, than this can be seen as a getter function of a byLine property and *both* forms should be applicable. So, that is my opinion about properties. I hope it makes some sense to you or is helpful to anyone. -- Gerrit
Jan 29 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-29 17:22:11 -0500, Gerrit Wichert <gw green-stores.de> said:

 [skipping a long part]
 But I don't want to advertise any Perl, just hoping the idees behind
 Moose can be helpful. So back to D.
Objective-C properties look like that too. You declare a property with a name, a type and some flags (like readonly), and you can either provide your own accessor functions or tell the compiler to synthesize them. All this reminds me the debate about what to do with properties a long time ago. Walter finally settled for property, so that's what we have now. I don't really want to reopen the debate. Thinking about it, I'm wondering if property wouldn't be better named as accessor. After all, each function labeled property isn't a property in itself, it's an accessor for that property constituted of all the overloaded accessor functions having the same name. But that's just a small cosmetic issue and I don't mind very much.
 Now to your problem with byLine:
 
 Some said it should be stdin.byLine(), some others said it should be
 stdin.byLine. They invoked contradictory rules that led to contradictory
 conclusions.
If byLine internally constructs a new range instance that happens to use stdin for iterating by line, this to me ist clearly a function. And then the normal rules for calling a function in the D language must apply. This has nothing to do with properties. If you have a single ByLineRange instance stored in stdin that is simply handed out by the byLine function, than this can be seen as a getter function of a byLine property and *both* forms should be applicable.
I think that's not exactly how it should be. I'd rather say: if you can conceptualize stdin as containing a ByLineRange then it is fit as a property. The actual implementation of stdin and byLine shouldn't matter.
 So, that is my opinion about properties. I hope it makes some sense to
 you or is helpful to anyone.
It makes sense in that it's a valid way to think about properties. I just don't feel it's worth reopening that debate now that we have something. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 29 2010
prev sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Andrei Alexandrescu wrote:

 foreach (line; stdin.byLine()) { ... }

 vs.

 foreach (line; stdin.byLine) { ... }

 How do I choose?
byLine is a property. It is fetching a range on stdin. -Steve
Damn. I was sure the answer will be different.
byLine() is a function. It changes the state of stdin. Calling it consecutively will in general result in different return values. If there were two guys: stdin.currentLine (property) and stdin.nextLine(), it would be a different story. A property should act very much like a field. The advantages of properties are that they can be derived (not have a one-to-one relation with a storage location) or can do some clever caching/memoizing/logging. Omitting parentheses on an action just because you can is stupid. It actually makes the language less readable and less predictable. And all that for saving two keystrokes. -- Michiel Helvensteijn
Jan 28 2010
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Thu, Jan 28, 2010 at 1:55 PM, Michiel Helvensteijn
<m.helvensteijn.remove gmail.com> wrote:
 Andrei Alexandrescu wrote:

 foreach (line; stdin.byLine()) { ... }

 vs.

 foreach (line; stdin.byLine) { ... }

 How do I choose?
byLine is a property. =A0It is fetching a range on stdin. -Steve
Damn. I was sure the answer will be different.
byLine() is a function. It changes the state of stdin. Calling it consecutively will in general result in different return values. If there were two guys: stdin.currentLine (property) and stdin.nextLine(), it woul=
d
 be a different story.
That's not how it works, I think. Just calling byLine() by itself only returns a range struct. Consuming things from that range is what changes the state of stdin. --bb
Jan 28 2010
parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Bill Baxter wrote:

 byLine() is a function. It changes the state of stdin. Calling it
 consecutively will in general result in different return values. If there
 were two guys: stdin.currentLine (property) and stdin.nextLine(), it
 would be a different story.
That's not how it works, I think. Just calling byLine() by itself only returns a range struct. Consuming things from that range is what changes the state of stdin.
Ah, my bad. I was guessing. Still, returning a handle from a property that can change the state of the originating object is.. iffy. -- Michiel Helvensteijn
Jan 28 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michiel Helvensteijn wrote:
 Bill Baxter wrote:
 
 byLine() is a function. It changes the state of stdin. Calling it
 consecutively will in general result in different return values. If there
 were two guys: stdin.currentLine (property) and stdin.nextLine(), it
 would be a different story.
That's not how it works, I think. Just calling byLine() by itself only returns a range struct. Consuming things from that range is what changes the state of stdin.
Ah, my bad. I was guessing. Still, returning a handle from a property that can change the state of the originating object is.. iffy.
I agree. So where's the consensus? Things seemed so clear when people were beaten with property over their head. Andrei
Jan 28 2010
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Thu, Jan 28, 2010 at 2:11 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Michiel Helvensteijn wrote:
 Bill Baxter wrote:

 byLine() is a function. It changes the state of stdin. Calling it
 consecutively will in general result in different return values. If
 there
 were two guys: stdin.currentLine (property) and stdin.nextLine(), it
 would be a different story.
That's not how it works, I think. Just calling byLine() by itself only returns a range struct. Consuming things from that range is what changes the state of stdin.
Ah, my bad. I was guessing. Still, returning a handle from a property that can change the state of the originating object is.. iffy.
I agree. So where's the consensus? Things seemed so clear when people were beaten with property over their head.
I really don't see what the problem is there. You are arguing that car.wheels should not be a property simply because it would let me change the color of the wheels (which are part of the car's total state)? --bb
Jan 28 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 2:11 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Michiel Helvensteijn wrote:
 Bill Baxter wrote:

 byLine() is a function. It changes the state of stdin. Calling it
 consecutively will in general result in different return values. If
 there
 were two guys: stdin.currentLine (property) and stdin.nextLine(), it
 would be a different story.
That's not how it works, I think. Just calling byLine() by itself only returns a range struct. Consuming things from that range is what changes the state of stdin.
Ah, my bad. I was guessing. Still, returning a handle from a property that can change the state of the originating object is.. iffy.
I agree. So where's the consensus? Things seemed so clear when people were beaten with property over their head.
I really don't see what the problem is there. You are arguing that car.wheels should not be a property simply because it would let me change the color of the wheels (which are part of the car's total state)?
The problem is not localized change. The result of stdin.byLine changes the _entire_ stdin. Andrei
Jan 28 2010
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Thu, Jan 28, 2010 at 2:27 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 2:11 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Michiel Helvensteijn wrote:
 Bill Baxter wrote:

 byLine() is a function. It changes the state of stdin. Calling it
 consecutively will in general result in different return values. If
 there
 were two guys: stdin.currentLine (property) and stdin.nextLine(), it
 would be a different story.
That's not how it works, I think. Just calling byLine() by itself only returns a range struct. Consuming things from that range is what changes the state of stdin.
Ah, my bad. I was guessing. Still, returning a handle from a property that can change the state of the originating object is.. iffy.
I agree. So where's the consensus? Things seemed so clear when people were beaten with property over their head.
I really don't see what the problem is there. You are arguing that car.wheels should not be a property simply because it would let me change the color of the wheels (which are part of the car's total state)?
The problem is not localized change. The result of stdin.byLine changes the _entire_ stdin.
Ok, so you have no problem with a car.wheels returning a mutable wheels object? So it's only when the returned property can change the entire state (or a lot of the state?) that you have a problem? I don't understand how degree changes the acceptability. Doesn't seem like it should matter to me. --bb
Jan 28 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 2:27 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 2:11 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Michiel Helvensteijn wrote:
 Bill Baxter wrote:

 byLine() is a function. It changes the state of stdin. Calling it
 consecutively will in general result in different return values. If
 there
 were two guys: stdin.currentLine (property) and stdin.nextLine(), it
 would be a different story.
That's not how it works, I think. Just calling byLine() by itself only returns a range struct. Consuming things from that range is what changes the state of stdin.
Ah, my bad. I was guessing. Still, returning a handle from a property that can change the state of the originating object is.. iffy.
I agree. So where's the consensus? Things seemed so clear when people were beaten with property over their head.
I really don't see what the problem is there. You are arguing that car.wheels should not be a property simply because it would let me change the color of the wheels (which are part of the car's total state)?
The problem is not localized change. The result of stdin.byLine changes the _entire_ stdin.
Ok, so you have no problem with a car.wheels returning a mutable wheels object? So it's only when the returned property can change the entire state (or a lot of the state?) that you have a problem? I don't understand how degree changes the acceptability. Doesn't seem like it should matter to me.
If you access car.wheel, it is reasonable to repaint that wheel. The problem is that you can use car.wheel to repaint the car. Andrei
Jan 28 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:hjt449$5d8$1 digitalmars.com...
 Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 2:27 PM, Andrei Alexandrescu
 The problem is not localized change. The result of stdin.byLine changes 
 the
 _entire_ stdin.
Ok, so you have no problem with a car.wheels returning a mutable wheels object? So it's only when the returned property can change the entire state (or a lot of the state?) that you have a problem? I don't understand how degree changes the acceptability. Doesn't seem like it should matter to me.
If you access car.wheel, it is reasonable to repaint that wheel. The problem is that you can use car.wheel to repaint the car.
Ok, so you don't think a property of something should be able to change other parts of that something? Ok, I can understand that. But if that's so, then how would it be any better to be able to change something through the return value of one of that something's member functions? (Which, of course, is what stdin.byLine apperently already does.) Ie, Given this code: auto foo = stdin.byLine; foo.doSomethingThatAdvancesStdin(); How is it possible for that code to be bad when "byLine" is defined as a " property", but suddenly be perfectly fine when omittable parens are allowed and it's defined without " property", even though either way it's still the exact same code doing exactly the same thing and having exactly the same effects?
Jan 28 2010
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Thu, Jan 28, 2010 at 3:58 PM, Nick Sabalausky <a a.a> wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:hjt449$5d8$1 digitalmars.com...
 Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 2:27 PM, Andrei Alexandrescu
 The problem is not localized change. The result of stdin.byLine change=
s
 the
 _entire_ stdin.
Ok, so you have no problem with a car.wheels returning a mutable wheels object? So it's only when the returned property can change the entire state (or a lot of the state?) that you have a problem? I don't understand how degree changes the acceptability. =A0Doesn't see=
m
 like it should matter to me.
If you access car.wheel, it is reasonable to repaint that wheel. The problem is that you can use car.wheel to repaint the car.
Ok, so you don't think a property of something should be able to change other parts of that something? Ok, I can understand that. But if that's s=
o,
 then how would it be any better to be able to change something through th=
e
 return value of one of that something's member functions? (Which, of cour=
se,
 is what stdin.byLine apperently already does.)

 Ie, Given this code:

 auto foo =3D stdin.byLine;
 foo.doSomethingThatAdvancesStdin();

 How is it possible for that code to be bad when "byLine" is defined as a
 " property", but suddenly be perfectly fine when omittable parens are
 allowed and it's defined without " property", even though either way it's
 still the exact same code doing exactly the same thing and having exactly
 the same effects?
That's not a contradiction in Andrei's position at all. Because if there is no property, then all that dropping parens means is that it's a no-function argument. In the original D1 scheme, .foo just means foo is either field or a zero-arg function. Nothing more nothing less. The problem is that you can't tell if the coder meant it to be a property or not, and this bites you in cases like returning callable. --bb
Jan 28 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.47.1264724411.4461.digitalmars-d puremagic.com...
On Thu, Jan 28, 2010 at 3:58 PM, Nick Sabalausky <a a.a> wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:hjt449$5d8$1 digitalmars.com...
 Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 2:27 PM, Andrei Alexandrescu
 The problem is not localized change. The result of stdin.byLine 
 changes
 the
 _entire_ stdin.
Ok, so you have no problem with a car.wheels returning a mutable wheels object? So it's only when the returned property can change the entire state (or a lot of the state?) that you have a problem? I don't understand how degree changes the acceptability. Doesn't seem like it should matter to me.
If you access car.wheel, it is reasonable to repaint that wheel. The problem is that you can use car.wheel to repaint the car.
Ok, so you don't think a property of something should be able to change other parts of that something? Ok, I can understand that. But if that's so, then how would it be any better to be able to change something through the return value of one of that something's member functions? (Which, of course, is what stdin.byLine apperently already does.) Ie, Given this code: auto foo = stdin.byLine; foo.doSomethingThatAdvancesStdin(); How is it possible for that code to be bad when "byLine" is defined as a " property", but suddenly be perfectly fine when omittable parens are allowed and it's defined without " property", even though either way it's still the exact same code doing exactly the same thing and having exactly the same effects?
That's not a contradiction in Andrei's position at all. Because if there is no property, then all that dropping parens means is that it's a no-function argument.
I assume you meant "no-argument function". And yes, I already pointed out that would make it a no-argument function. And that's precisely my point. If we accept that it's bad to paint a car via its " property" wheel, then how can we possibly accept this to not be just as bad?: auto car = new Car(); auto wheel = car.getWheel_ThisIsAFunctionNotAProperty(); wheel.paintTheCar();
Jan 28 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Bill Baxter" <wbaxter gmail.com> wrote in message 
 news:mailman.47.1264724411.4461.digitalmars-d puremagic.com...
 On Thu, Jan 28, 2010 at 3:58 PM, Nick Sabalausky <a a.a> wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:hjt449$5d8$1 digitalmars.com...
 Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 2:27 PM, Andrei Alexandrescu
 The problem is not localized change. The result of stdin.byLine 
 changes
 the
 _entire_ stdin.
Ok, so you have no problem with a car.wheels returning a mutable wheels object? So it's only when the returned property can change the entire state (or a lot of the state?) that you have a problem? I don't understand how degree changes the acceptability. Doesn't seem like it should matter to me.
If you access car.wheel, it is reasonable to repaint that wheel. The problem is that you can use car.wheel to repaint the car.
Ok, so you don't think a property of something should be able to change other parts of that something? Ok, I can understand that. But if that's so, then how would it be any better to be able to change something through the return value of one of that something's member functions? (Which, of course, is what stdin.byLine apperently already does.) Ie, Given this code: auto foo = stdin.byLine; foo.doSomethingThatAdvancesStdin(); How is it possible for that code to be bad when "byLine" is defined as a " property", but suddenly be perfectly fine when omittable parens are allowed and it's defined without " property", even though either way it's still the exact same code doing exactly the same thing and having exactly the same effects?
That's not a contradiction in Andrei's position at all. Because if there is no property, then all that dropping parens means is that it's a no-function argument.
I assume you meant "no-argument function". And yes, I already pointed out that would make it a no-argument function. And that's precisely my point. If we accept that it's bad to paint a car via its " property" wheel, then how can we possibly accept this to not be just as bad?: auto car = new Car(); auto wheel = car.getWheel_ThisIsAFunctionNotAProperty(); wheel.paintTheCar();
Because a function doesn't attempt to emulate a field. Andrei
Jan 28 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:hjtcbd$r0a$1 digitalmars.com...
 Nick Sabalausky wrote:
 And yes, I already pointed out that would make it a no-argument function. 
 And that's precisely my point. If we accept that it's bad to paint a car 
 via its " property" wheel, then how can we possibly accept this to not be 
 just as bad?:

 auto car = new Car();
 auto wheel = car.getWheel_ThisIsAFunctionNotAProperty();
 wheel.paintTheCar();
Because a function doesn't attempt to emulate a field.
D's approach to properties *forces* functions to emulate fields.
Jan 28 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:hjtcbd$r0a$1 digitalmars.com...
 Nick Sabalausky wrote:
 And yes, I already pointed out that would make it a no-argument function. 
 And that's precisely my point. If we accept that it's bad to paint a car 
 via its " property" wheel, then how can we possibly accept this to not be 
 just as bad?:

 auto car = new Car();
 auto wheel = car.getWheel_ThisIsAFunctionNotAProperty();
 wheel.paintTheCar();
Because a function doesn't attempt to emulate a field.
D's approach to properties *forces* functions to emulate fields.
Unfortunately not. It forces nothing. That's my problem with the feature - it's nothing more than fostering a convention. Andrei
Jan 28 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:hjtet5$111d$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:hjtcbd$r0a$1 digitalmars.com...
 Nick Sabalausky wrote:
 And yes, I already pointed out that would make it a no-argument 
 function. And that's precisely my point. If we accept that it's bad to 
 paint a car via its " property" wheel, then how can we possibly accept 
 this to not be just as bad?:

 auto car = new Car();
 auto wheel = car.getWheel_ThisIsAFunctionNotAProperty();
 wheel.paintTheCar();
Because a function doesn't attempt to emulate a field.
D's approach to properties *forces* functions to emulate fields.
Unfortunately not. It forces nothing. That's my problem with the feature - it's nothing more than fostering a convention.
A programming language *is* a set of enforced conventions. When something either can't be enforced mechanically (ex: accurate and meaningful variable names), or has real practical value in not having an enforced convention (ex: user-definable variable names, free-form whitespace, underscores in numeric literals), that's when it's left to the users to make up their own arbitrary and likely-conflicting conventions. Arbitrary freedoms just for the sake of it: great in real life, lousy in a programming language. If we don't enforce the convention of (non-property) functions being called with parens, the only things gained besides that useless "arbitrary freedom in a programming language just for the sake of it" is a couple fewer keystrokes and an extremely minuscule reduction in alleged "noise" (the usefulness of which is easily canceled out by the fact that reduction in inconsistency improves readability too).
Jan 28 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:hjtl33$1dag$1 digitalmars.com...
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:hjtet5$111d$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:hjtcbd$r0a$1 digitalmars.com...
 Nick Sabalausky wrote:
 And yes, I already pointed out that would make it a no-argument 
 function. And that's precisely my point. If we accept that it's bad to 
 paint a car via its " property" wheel, then how can we possibly accept 
 this to not be just as bad?:

 auto car = new Car();
 auto wheel = car.getWheel_ThisIsAFunctionNotAProperty();
 wheel.paintTheCar();
Because a function doesn't attempt to emulate a field.
D's approach to properties *forces* functions to emulate fields.
Unfortunately not. It forces nothing. That's my problem with the feature - it's nothing more than fostering a convention.
A programming language *is* a set of enforced conventions. When something either can't be enforced mechanically (ex: accurate and meaningful variable names), or has real practical value in not having an enforced convention (ex: user-definable variable names, free-form whitespace, underscores in numeric literals), that's when it's left to the users to make up their own arbitrary and likely-conflicting conventions. Arbitrary freedoms just for the sake of it: great in real life, lousy in a programming language. If we don't enforce the convention of (non-property) functions being called with parens, the only things gained besides that useless "arbitrary freedom in a programming language just for the sake of it" is a couple fewer keystrokes and an extremely minuscule reduction in alleged "noise" (the usefulness of which is easily canceled out by the fact that reduction in inconsistency improves readability too).
We can keep dancing around it with different evidence, metaphors and philosophies all we want, but the bottom line is, omittable parens are a feature, and they just happen to be a feature that 1. causes problems and 2. provides extremely minimal benefits. And what do we do with features that cause problems and provide extremely minimal benefits? We yank 'em.
Jan 28 2010
parent Justin Johansson <no spam.com> writes:
Nick Sabalausky wrote:
 "Nick Sabalausky" <a a.a> wrote in message 
 news:hjtl33$1dag$1 digitalmars.com...
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:hjtet5$111d$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:hjtcbd$r0a$1 digitalmars.com...
 Nick Sabalausky wrote:
 And yes, I already pointed out that would make it a no-argument 
 function. And that's precisely my point. If we accept that it's bad to 
 paint a car via its " property" wheel, then how can we possibly accept 
 this to not be just as bad?:

 auto car = new Car();
 auto wheel = car.getWheel_ThisIsAFunctionNotAProperty();
 wheel.paintTheCar();
Because a function doesn't attempt to emulate a field.
D's approach to properties *forces* functions to emulate fields.
Unfortunately not. It forces nothing. That's my problem with the feature - it's nothing more than fostering a convention.
A programming language *is* a set of enforced conventions. When something either can't be enforced mechanically (ex: accurate and meaningful variable names), or has real practical value in not having an enforced convention (ex: user-definable variable names, free-form whitespace, underscores in numeric literals), that's when it's left to the users to make up their own arbitrary and likely-conflicting conventions. Arbitrary freedoms just for the sake of it: great in real life, lousy in a programming language. If we don't enforce the convention of (non-property) functions being called with parens, the only things gained besides that useless "arbitrary freedom in a programming language just for the sake of it" is a couple fewer keystrokes and an extremely minuscule reduction in alleged "noise" (the usefulness of which is easily canceled out by the fact that reduction in inconsistency improves readability too).
We can keep dancing around it with different evidence, metaphors and philosophies all we want, but the bottom line is, omittable parens are a feature, and they just happen to be a feature that 1. causes problems and 2. provides extremely minimal benefits. And what do we do with features that cause problems and provide extremely minimal benefits? We yank 'em.
Creeping elegance is the root of all evil.*** (***Variation on a theme attributed to exactly-one famous computer scientist.) Best wishes, Justin Johansson
Jan 29 2010
prev sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Nick Sabalausky wrote:

 A programming language *is* a set of enforced conventions. When something 
 either can't be enforced mechanically (ex: accurate and meaningful variable 
 names), or has real practical value in not having an enforced convention 
 (ex: user-definable variable names, free-form whitespace, underscores in 
 numeric literals), that's when it's left to the users to make up their own 
 arbitrary and likely-conflicting conventions. Arbitrary freedoms just for 
 the sake of it: great in real life, lousy in a programming language.

 If we don't enforce the convention of (non-property) functions being called 
 with parens, the only things gained besides that useless "arbitrary freedom 
 in a programming language just for the sake of it" is a couple fewer 
 keystrokes and an extremely minuscule reduction in alleged "noise" (the 
 usefulness of which is easily canceled out by the fact that reduction in 
 inconsistency improves readability too).
I agree. If we do not require parentheses on functions then there is no benefit to having property. I was on the side of not having a special "property" syntax. However the DIP4 example "ambiguous-looking code" was enough to make me happy to see Java... I've just been assuming properties have not yet been finished. And maybe we will get +=,-= in the future.
Jan 28 2010
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 28 Jan 2010 20:51:29 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message  
 news:hjtcbd$r0a$1 digitalmars.com...
 Nick Sabalausky wrote:
 And yes, I already pointed out that would make it a no-argument  
 function. And that's precisely my point. If we accept that it's bad  
 to paint a car via its " property" wheel, then how can we possibly  
 accept this to not be just as bad?:

 auto car = new Car();
 auto wheel = car.getWheel_ThisIsAFunctionNotAProperty();
 wheel.paintTheCar();
Because a function doesn't attempt to emulate a field.
D's approach to properties *forces* functions to emulate fields.
Unfortunately not. It forces nothing. That's my problem with the feature - it's nothing more than fostering a convention.
It forces a convention. The convention is important, almost as important as the name of the function. Think of it as an extension of the function name, like extra punctuation that changes the human interpretation of the function. It means you must be explicit what you intend, the parentheses become a detail that is important to the compiler. If we adopted a convention where you could do: int x, y; int z = x y; implying that x should be added to y, then that would certainly work. But what value does it add (no pun intended)? Did the user intend to add them, or did he just make a typo? The convention of requiring the operator forces you to create unambiguous code, just like requiring the parentheses forces you to declare your expectation of the function. -Steve
Jan 29 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Thu, 28 Jan 2010 20:51:29 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in 
 message news:hjtcbd$r0a$1 digitalmars.com...
 Nick Sabalausky wrote:
 And yes, I already pointed out that would make it a no-argument 
 function. And that's precisely my point. If we accept that it's bad 
 to paint a car via its " property" wheel, then how can we possibly 
 accept this to not be just as bad?:

 auto car = new Car();
 auto wheel = car.getWheel_ThisIsAFunctionNotAProperty();
 wheel.paintTheCar();
Because a function doesn't attempt to emulate a field.
D's approach to properties *forces* functions to emulate fields.
Unfortunately not. It forces nothing. That's my problem with the feature - it's nothing more than fostering a convention.
It forces a convention.
It forces you to define a convention as vacuous and open to interpretation as any other. Not a quantum leap I reckon. Andrei
Jan 29 2010
prev sibling parent Rainer Deyke <rainerd eldwood.com> writes:
Andrei Alexandrescu wrote:
 Nick Sabalausky wrote:
 auto car = new Car();
 auto wheel = car.getWheel_ThisIsAFunctionNotAProperty();
 wheel.paintTheCar();
Because a function doesn't attempt to emulate a field.
Not really relevant, since the same applies to fields. auto car = new Car(); auto wheel = car.wheelFieldnotPropertyOrFunction; wheel.paintTheCar(); In this case, the wheel field contains a pointer back to the car. -- Rainer Deyke - rainerd eldwood.com
Jan 29 2010
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-28 17:27:58 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 The problem is not localized change. The result of stdin.byLine changes 
 the _entire_ stdin.
No. Calling byLine doesn't change the stream. It returns a different view of stdin, which can be used to modify the stream, or not. I think it should be a property. If it was 'getNextLine' then it should be a function. As a proof, this doesn't have any effect: stdin.byLine; If you put it in a foreach loop, then it has an effect. But it's foreach that has the effect of calling popFront on the byLine view of stdin. Getting byLine by itself doesn't do anything. Another term I'd use for a property, perhaps a better one, is an 'accessor'. A property, or an accessor, gives you access to an aspect of the object you're dealing with. In the case above, you get access to stdin line by line. Getting access to something might allow you to modify it, or it may not, depending on what it is exactly. But just getting access to it doesn't modify the object in itself. Sorry to arrive late in this conversation. Let me address some other points: I know not everyone get it right all the time. But that's not necessarily a contradiction, it just means that the concept isn't really well understood. If there was a good definition for it from an authoritative reference, it might help reduce the confusion. Currently the only authoritative element seems to be the syntax, no wonder it's confusing. Andrei, you keep complaining it's a convention. It *is* a convention, because only a convention can differentiate actions from accessors. Ideally, we wouldn't need a special syntax: English words would be enough. But as you know English words alone are often ambiguous. Either the convention is (1) how we name things -- like isEmpty vs. empty -- but I think you don't like that. Either it's (2) a syntactic convention -- empty vs. empty() -- but then the meaning becomes a little more subtle. Or (3) you can give the same meaning to both empty and empty(), but then people are left to guess what it means (action or accessor), and it creates incongruities with callables. Or (4) you can force empty() to always be with parenthesis and let people guess what it means; at least you don't have incongruities. There's no perfect solution. But of all of these options, the one used in D1 (number 3) has the most drawbacks: you can't distinguish actions from accessors, and on top of that you have problems with returning callables. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 28 2010
next sibling parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/29/2010 05:48 AM, Michel Fortin wrote:
 No. Calling byLine doesn't change the stream. It returns a different
 view of stdin, which can be used to modify the stream, or not. I think
 it should be a property. If it was 'getNextLine' then it should be a
 function. As a proof, this doesn't have any effect:

 stdin.byLine;
It reads a line off stdin. Try it.
Jan 29 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-29 06:25:44 -0500, Pelle Månsson <pelle.mansson gmail.com> said:

 On 01/29/2010 05:48 AM, Michel Fortin wrote:
 
 No. Calling byLine doesn't change the stream. It returns a different
 view of stdin, which can be used to modify the stream, or not. I think
 it should be a property. If it was 'getNextLine' then it should be a
 function. As a proof, this doesn't have any effect:
 
 stdin.byLine;
It reads a line off stdin. Try it.
Ah, I see, you're right. Silly me for not trying. So it's not an accessor after all. The problem is that, even disregarding the property syntax, the name strongly suggests it's an accessor, but it has side effects, which it shouldn't. Either we change the name to something else, like 'consumeLines()', or we make it behave like an accessor. I'd go for the second option. The basic problem lies in the very basic definition of an input range. Due to its interface (popFront + front), an input range is forced to consume the its first element by its mere existence. I think constructing an input range shouldn't have side effects. It should be more symmetrical with an output range. It could have just one function, 'take' to get the next element, and now byLine could work correctly. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 29 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 08:03:13 -0500, Michel Fortin  
<michel.fortin michelf.com> wrote:

 On 2010-01-29 06:25:44 -0500, Pelle MÃ¥nsson <pelle.mansson gmail.com>  
 said:

 On 01/29/2010 05:48 AM, Michel Fortin wrote:
  No. Calling byLine doesn't change the stream. It returns a different
 view of stdin, which can be used to modify the stream, or not. I think
 it should be a property. If it was 'getNextLine' then it should be a
 function. As a proof, this doesn't have any effect:
  stdin.byLine;
It reads a line off stdin. Try it.
Ah, I see, you're right. Silly me for not trying. So it's not an accessor after all. The problem is that, even disregarding the property syntax, the name strongly suggests it's an accessor, but it has side effects, which it shouldn't. Either we change the name to something else, like 'consumeLines()', or we make it behave like an accessor. I'd go for the second option. The basic problem lies in the very basic definition of an input range. Due to its interface (popFront + front), an input range is forced to consume the its first element by its mere existence. I think constructing an input range shouldn't have side effects. It should be more symmetrical with an output range. It could have just one function, 'take' to get the next element, and now byLine could work correctly.
Hey, it's that dead horse again, let's beat it! Andrei and I and several others discussed this ad infinitum. You will never convince Andrei that his design is wrong :) The truth is, the fact that byLine modifies stdin by its mere existence proves to be inconsequential. Nobody will fetch the byLine property without using it. It's still an accessor. -Steve
Jan 29 2010
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-29 08:18:46 -0500, "Steven Schveighoffer" 
<schveiguy yahoo.com> said:

 Hey, it's that dead horse again, let's beat it!
 
 Andrei and I and several others discussed this ad infinitum.  You will  
 never convince Andrei that his design is wrong :)
Andrei is the one who complained that it's difficult to know whether 'byLine' is a property in the first place. I'm just explaining why it is, and what should be done. I'm starting to think Anrei likes ambiguous semantics. :-)
 The truth is, the fact that byLine modifies stdin by its mere existence 
  proves to be inconsequential.  Nobody will fetch the byLine property  
 without using it.  It's still an accessor.
That's only true if you use byLine exclusively. Here is a case where the advance fetching of byLine could go wrong: // fetch 3 lines: string[] consume(3, stdin.byLine); // now fill a buffer ubyte[] buffer; buffer = stdin.rawRead(buffer); E[] consume(E, R)(int count, R range) { E[] elements; foreach (i; 0..count) { elements ~= range.front; range.popFront(); } return elements; } The problem here is that the consume() function will in reality consume 4 lines of stdin, even though it just take 3 from byLine. When we later call rawRead, a line has been lost. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 29 2010
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 09:34:25 -0500, Michel Fortin  
<michel.fortin michelf.com> wrote:

 On 2010-01-29 08:18:46 -0500, "Steven Schveighoffer"  
 <schveiguy yahoo.com> said:

 Hey, it's that dead horse again, let's beat it!
  Andrei and I and several others discussed this ad infinitum.  You  
 will  never convince Andrei that his design is wrong :)
Andrei is the one who complained that it's difficult to know whether 'byLine' is a property in the first place. I'm just explaining why it is, and what should be done.
I agree.
 I'm starting to think Anrei likes ambiguous semantics.  :-)


 The truth is, the fact that byLine modifies stdin by its mere existence  
  proves to be inconsequential.  Nobody will fetch the byLine property   
 without using it.  It's still an accessor.
That's only true if you use byLine exclusively. Here is a case where the advance fetching of byLine could go wrong: // fetch 3 lines: string[] consume(3, stdin.byLine); // now fill a buffer ubyte[] buffer; buffer = stdin.rawRead(buffer); E[] consume(E, R)(int count, R range) { E[] elements; foreach (i; 0..count) { elements ~= range.front; range.popFront(); } return elements; } The problem here is that the consume() function will in reality consume 4 lines of stdin, even though it just take 3 from byLine. When we later call rawRead, a line has been lost.
Yeah, I am on your side. byLine has some nuances that make it incompatible with other uses of the stream. In fact, byLine might only be useful in processing the entire file. Hm... opApply? -Steve
Jan 29 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 On 2010-01-29 08:18:46 -0500, "Steven Schveighoffer" 
 <schveiguy yahoo.com> said:
 
 Hey, it's that dead horse again, let's beat it!

 Andrei and I and several others discussed this ad infinitum.  You 
 will  never convince Andrei that his design is wrong :)
Andrei is the one who complained that it's difficult to know whether 'byLine' is a property in the first place. I'm just explaining why it is, and what should be done. I'm starting to think Anrei likes ambiguous semantics. :-)
I'll tell you what I'd have liked: a landslide of responses to my question revealing my mistaken ways and clarifying without a shade of a doubt that byLine should be a property. Or not. (I don't even care which.) The fact we're having a debate about this (and Steve even says it's a clear cut case and there are other more ambiguous!) is worrisome. Take this: I got different answers from _supporters_ of property! A good convention is one that you apply without wasting time to think of it every single time you use it: naming conventions, braces conventions, even most class vs. struct conventions. The well-defined ones work great because _they save you time_. This property stuff doesn't save anyone time (the provider is aggravated and the client is aggravated too). Honest, I think it's quite a misfeature. If there's a possibility to fix the ambiguities of the old system, I'd kick property into oblivion today. We need digitalmars.D.is_it_a_property_or_not. Whenever in doubt, people can ask a question there. Andrei
Jan 29 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 10:40:23 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Michel Fortin wrote:
 On 2010-01-29 08:18:46 -0500, "Steven Schveighoffer"  
 <schveiguy yahoo.com> said:

 Hey, it's that dead horse again, let's beat it!

 Andrei and I and several others discussed this ad infinitum.  You  
 will  never convince Andrei that his design is wrong :)
Andrei is the one who complained that it's difficult to know whether 'byLine' is a property in the first place. I'm just explaining why it is, and what should be done. I'm starting to think Anrei likes ambiguous semantics. :-)
I'll tell you what I'd have liked: a landslide of responses to my question revealing my mistaken ways and clarifying without a shade of a doubt that byLine should be a property. Or not. (I don't even care which.)
It's been mentioned before that tough decisions need to be made in many areas of programming. Deciding what is a property and what is not is no different. Using byLine as the strawman does not disprove the usefulness of properties.
 The fact we're having a debate about this (and Steve even says it's a  
 clear cut case and there are other more ambiguous!) is worrisome. Take  
 this: I got different answers from _supporters_ of  property!
Again, property cannot provide an intuitive solution for everything, just like ranges cannot solve everything.
 A good convention is one that you apply without wasting time to think of  
 it every single time you use it: naming conventions, braces conventions,  
 even most class vs. struct conventions. The well-defined ones work great  
 because _they save you time_. This  property stuff doesn't save anyone  
 time (the provider is aggravated and the client is aggravated too).  
 Honest, I think it's quite a misfeature. If there's a possibility to fix  
 the ambiguities of the old system, I'd kick  property into oblivion  
 today.
The only one you stated here that is on par with property is naming conventions. They don't save you time writing code, they save you time *reading* code. The work goes into the writing (how to name this properly? How to make the name intuitive?) and then when reading, it comes natural. Without property you lose part of that concept. The parentheses are an extension of the symbol name, defined by the author, nothing more. What this *means* is up to you. In fact, properties *are* an extension of naming conventions.
 We need digitalmars.D.is_it_a_property_or_not. Whenever in doubt, people  
 can ask a question there.
OK: digitalmars.d.should_this_be_a_class_or_struct. digitalmars.d.should_this_symbol_be_capitalized. digitalmars.d.should_this_use_a_function_pointer_or_delegate. digitalmars.d.should_this_be_const_or_immutable. Can we ever get any work done without these? -Steve
Jan 29 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 10:40:23 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Michel Fortin wrote:
 On 2010-01-29 08:18:46 -0500, "Steven Schveighoffer" 
 <schveiguy yahoo.com> said:

 Hey, it's that dead horse again, let's beat it!

 Andrei and I and several others discussed this ad infinitum.  You 
 will  never convince Andrei that his design is wrong :)
Andrei is the one who complained that it's difficult to know whether 'byLine' is a property in the first place. I'm just explaining why it is, and what should be done. I'm starting to think Anrei likes ambiguous semantics. :-)
I'll tell you what I'd have liked: a landslide of responses to my question revealing my mistaken ways and clarifying without a shade of a doubt that byLine should be a property. Or not. (I don't even care which.)
It's been mentioned before that tough decisions need to be made in many areas of programming. Deciding what is a property and what is not is no different.
Except it has no reward associated with it. Andrei
Jan 29 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 11:17:04 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 10:40:23 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 Michel Fortin wrote:
 On 2010-01-29 08:18:46 -0500, "Steven Schveighoffer"  
 <schveiguy yahoo.com> said:

 Hey, it's that dead horse again, let's beat it!

 Andrei and I and several others discussed this ad infinitum.  You  
 will  never convince Andrei that his design is wrong :)
Andrei is the one who complained that it's difficult to know whether 'byLine' is a property in the first place. I'm just explaining why it is, and what should be done. I'm starting to think Anrei likes ambiguous semantics. :-)
I'll tell you what I'd have liked: a landslide of responses to my question revealing my mistaken ways and clarifying without a shade of a doubt that byLine should be a property. Or not. (I don't even care which.)
It's been mentioned before that tough decisions need to be made in many areas of programming. Deciding what is a property and what is not is no different.
Except it has no reward associated with it.
Clarity. Disambiguation. All the rewards that come from other naming conventions. Sorry you don't see it that way. -Steve
Jan 29 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:17:04 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 10:40:23 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Michel Fortin wrote:
 On 2010-01-29 08:18:46 -0500, "Steven Schveighoffer" 
 <schveiguy yahoo.com> said:

 Hey, it's that dead horse again, let's beat it!

 Andrei and I and several others discussed this ad infinitum.  You 
 will  never convince Andrei that his design is wrong :)
Andrei is the one who complained that it's difficult to know whether 'byLine' is a property in the first place. I'm just explaining why it is, and what should be done. I'm starting to think Anrei likes ambiguous semantics. :-)
I'll tell you what I'd have liked: a landslide of responses to my question revealing my mistaken ways and clarifying without a shade of a doubt that byLine should be a property. Or not. (I don't even care which.)
It's been mentioned before that tough decisions need to be made in many areas of programming. Deciding what is a property and what is not is no different.
Except it has no reward associated with it.
Clarity. Disambiguation. All the rewards that come from other naming conventions. Sorry you don't see it that way.
How is f.byLine clearer and less ambiguous than f.byLine()? Or vice versa for that matter? Andrei
Jan 29 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 How is f.byLine clearer and less ambiguous than f.byLine()? Or vice  
 versa for that matter?
Note that properties can be named things other than byLine. -Steve
Jan 29 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 How is f.byLine clearer and less ambiguous than f.byLine()? Or vice 
 versa for that matter?
Note that properties can be named things other than byLine. -Steve
What I meant to say is that in the property landscape the following two conventions become suddenly attractive: * Do not use property at all * Use property for all nullary functions And they're bound to save a lot of time to everyone involved. Andrei
Jan 29 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 11:29:22 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 How is f.byLine clearer and less ambiguous than f.byLine()? Or vice  
 versa for that matter?
Note that properties can be named things other than byLine. -Steve
What I meant to say is that in the property landscape the following two conventions become suddenly attractive: * Do not use property at all * Use property for all nullary functions And they're bound to save a lot of time to everyone involved.
I think we all agree that setters the way D1 does them are very prone to abuse. So all that is left is no-argument functions. There are other alternative conventions to what you stated. This is my convention: * use property where the main purpose of the function is to fetch a value (computed or not, modifying the container or not) There are others mentioned in this thread. A property convention is useful to readers of the code. The existence of the property feature makes it *possible* to define conventions -- it doesn't define a convention itself. -Steve
Jan 29 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:29:22 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 How is f.byLine clearer and less ambiguous than f.byLine()? Or vice 
 versa for that matter?
Note that properties can be named things other than byLine. -Steve
What I meant to say is that in the property landscape the following two conventions become suddenly attractive: * Do not use property at all * Use property for all nullary functions And they're bound to save a lot of time to everyone involved.
I think we all agree that setters the way D1 does them are very prone to abuse. So all that is left is no-argument functions. There are other alternative conventions to what you stated. This is my convention: * use property where the main purpose of the function is to fetch a value (computed or not, modifying the container or not)
Consider: struct Stack(T) { T pop(); ... } By your definition, pop() should be a property. It doesn't quite strike me as an intuitive decision. Andrei
Jan 29 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 12:23:24 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:29:22 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 How is f.byLine clearer and less ambiguous than f.byLine()? Or vice  
 versa for that matter?
Note that properties can be named things other than byLine. -Steve
What I meant to say is that in the property landscape the following two conventions become suddenly attractive: * Do not use property at all * Use property for all nullary functions And they're bound to save a lot of time to everyone involved.
I think we all agree that setters the way D1 does them are very prone to abuse. So all that is left is no-argument functions. There are other alternative conventions to what you stated. This is my convention: * use property where the main purpose of the function is to fetch a value (computed or not, modifying the container or not)
Consider: struct Stack(T) { T pop(); ... } By your definition, pop() should be a property. It doesn't quite strike me as an intuitive decision.
is pop's main purpose to fetch a value or to modify the stack? I'd say the purpose is split equally, so it's not a function whose main purpose is to fetch a value. I admit this is a good example where a judgement call comes into play, but we aren't all robots obeying every rule literally. There are sometimes exceptions in conventions, or at least the rule is subject to interpretation. -Steve
Jan 29 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 12:23:24 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:29:22 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 How is f.byLine clearer and less ambiguous than f.byLine()? Or 
 vice versa for that matter?
Note that properties can be named things other than byLine. -Steve
What I meant to say is that in the property landscape the following two conventions become suddenly attractive: * Do not use property at all * Use property for all nullary functions And they're bound to save a lot of time to everyone involved.
I think we all agree that setters the way D1 does them are very prone to abuse. So all that is left is no-argument functions. There are other alternative conventions to what you stated. This is my convention: * use property where the main purpose of the function is to fetch a value (computed or not, modifying the container or not)
Consider: struct Stack(T) { T pop(); ... } By your definition, pop() should be a property. It doesn't quite strike me as an intuitive decision.
is pop's main purpose to fetch a value or to modify the stack? I'd say the purpose is split equally, so it's not a function whose main purpose is to fetch a value.
So now we're down to proportions, nuance, and where "main" goes. You made my point. I win.
 I admit this is a good example where a judgement 
 call comes into play, but we aren't all robots obeying every rule 
 literally.
If that's not enough, I have many others. With braces or names, I obey rules literally without any trouble. The problem with property is, there are too many exceptions, judgment calls, and edge cases.
 There are sometimes exceptions in conventions, or at least 
 the rule is subject to interpretation.
Which brings home my point: the entire business of deciding property or not is a waste of everyone's time. There's no simple rule, and there's no advantage to be gained after having made the decision one way or another. Andrei
Jan 29 2010
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 12:56:43 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 So now we're down to proportions, nuance, and where "main" goes. You  
 made my point. I win.
You just don't get it. declaring property or not is part of naming the function. Any naming convention either can have strict rules or not. You cited two very strict naming conventions, I cited a not-so-strict one, one that is open to interpretation. A similar naming convention in Java is the "isX" being a boolean property. Well, that doesn't always work because english doesn't always follow strict rules. Same thing for properties. I don't know what you think you've won. I never said properties make every possible function name intuitive.
 I admit this is a good example where a judgement call comes into play,  
 but we aren't all robots obeying every rule literally.
If that's not enough, I have many others. With braces or names, I obey rules literally without any trouble. The problem with property is, there are too many exceptions, judgment calls, and edge cases.
We went through scores of threads dissecting the names for range methods and what they should be. Does that mean that ranges are useless because we had to waste so much time naming their functions? The fact that we are arguing over one stupid function for this long is mind-boggling. Drop the straw man and look at the big picture. MOST OF THE TIME it is useful and intuitive. If that's not worth anything to you, then I don't know what else to say.
 There are sometimes exceptions in conventions, or at least the rule is  
 subject to interpretation.
Which brings home my point: the entire business of deciding property or not is a waste of everyone's time. There's no simple rule, and there's no advantage to be gained after having made the decision one way or another.
No, there is no simple rule, just like there's no simple rule for symbol names. If you spend the time to name your properties correctly, the intuition provided saves all your users from wasting time looking up the documentation. It saves reviewers from wasting time looking up documentation to understand what a coder is doing. It's not a waste of time if it has benefits, and it does. You just refuse to believe it. -Steve
Jan 29 2010
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-29 12:56:43 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 12:23:24 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 Consider:
 
 struct Stack(T) {
      T pop();
      ...
 }
 
 By your definition, pop() should be a property. It doesn't quite strike 
 me as an intuitive decision.
is pop's main purpose to fetch a value or to modify the stack? I'd say the purpose is split equally, so it's not a function whose main purpose is to fetch a value.
So now we're down to proportions, nuance, and where "main" goes. You made my point. I win.
You win because Steven's definition is not good enough. I said before that we should have a authoritative definition. If we really can't define how a property should be defined after some reflection, then you really win. My definition is that a property gives access to an aspect of an object and doesn't modify it (the getter is essentially logical-const). In this case, 'pop' doesn't give you access to something in the stack, it removes an element (that's an action) and give you the element. It's pretty clear that 'pop' is used as a verb here, that should be enough to decide it's a function. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 29 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 On 2010-01-29 12:56:43 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 12:23:24 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 Consider:

 struct Stack(T) {
      T pop();
      ...
 }

 By your definition, pop() should be a property. It doesn't quite 
 strike me as an intuitive decision.
is pop's main purpose to fetch a value or to modify the stack? I'd say the purpose is split equally, so it's not a function whose main purpose is to fetch a value.
So now we're down to proportions, nuance, and where "main" goes. You made my point. I win.
You win because Steven's definition is not good enough. I said before that we should have a authoritative definition. If we really can't define how a property should be defined after some reflection, then you really win. My definition is that a property gives access to an aspect of an object and doesn't modify it (the getter is essentially logical-const).
Ok this makes sense. So something is a property if fetching it doesn't mess up the parent object. (Maybe properties should be pure even.) The lingering question is whether you can later use the fetched property to operate change in the parent object. I guess that it's reasonable to leave that up to the person defining the object and its property. I guess that's a set of rules that is simple, borderline meaningful, and easy to follow. By that logic File.byLine is a property, Stack.pop() is a function, Stack.top and Stack.empty are properties etc. That being said, I agree with Pelle that actions invoked without parens are darn attractive. Andrei
Jan 29 2010
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 13:52:25 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Michel Fortin wrote:
  My definition is that a property gives access to an aspect of an  
 object and doesn't modify it (the getter is essentially logical-const).
Ok this makes sense. So something is a property if fetching it doesn't mess up the parent object. (Maybe properties should be pure even.)
No, because pure implies that the object must be immutable. They should be inout (if indeed they do not modify the object). But you have some problems there. Whether it logically modifies the object or not (I hate to use it, but byLine.front as proposed would have to not be inout) is subject to interpretation. I think it should not be a hard requirement, and at best should be expected to possibly mutate private state.
 The lingering question is whether you can later use the fetched property  
 to operate change in the parent object. I guess that it's reasonable to  
 leave that up to the person defining the object and its property.
It isn't any different than using a field to modify the parent's state. Not modifying the parent's state is simply not in the charter for properties. It's too strict, and doesn't follow the abilities of that which it is modeled after.
 That being said, I agree with Pelle that actions invoked without parens  
 are darn attractive.
To each his own. I find them unclean and ambiguous. -Steve
Jan 29 2010
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-29 13:52:25 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Ok this makes sense. So something is a property if fetching it doesn't 
 mess up the parent object. (Maybe properties should be pure even.)
Logical-pure, to be precise. ;-)
 The lingering question is whether you can later use the fetched 
 property to operate change in the parent object. I guess that it's 
 reasonable to leave that up to the person defining the object and its 
 property.
You can already do that with fields, so it make sense you can with properties too: class A { B b; } struct B { int c; } A a; a.b.c = 1; // works!
 I guess that's a set of rules that is simple, borderline meaningful, 
 and easy to follow. By that logic File.byLine is a property, 
 Stack.pop() is a function, Stack.top and Stack.empty are properties etc.
 
 That being said, I agree with Pelle that actions invoked without parens 
 are darn attractive.
And I agree too, they're attractive. But in a programming language I prefer to deal with less ambiguities even if it means a few more parenthesis. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 29 2010
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 13:41:43 -0500, Michel Fortin  
<michel.fortin michelf.com> wrote:

 On 2010-01-29 12:56:43 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> said:

 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 12:23:24 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:
 Consider:
  struct Stack(T) {
      T pop();
      ...
 }
  By your definition, pop() should be a property. It doesn't quite  
 strike me as an intuitive decision.
is pop's main purpose to fetch a value or to modify the stack? I'd say the purpose is split equally, so it's not a function whose main purpose is to fetch a value.
So now we're down to proportions, nuance, and where "main" goes. You made my point. I win.
You win because Steven's definition is not good enough. I said before that we should have a authoritative definition. If we really can't define how a property should be defined after some reflection, then you really win.
Be careful here, don't give Andrei hard criteria for declaring victory ;) But my larger point was that convention is convention, whether you use parentheses to designate what a function does, or the symbol name itself. Deciding the convention is liable to suit some and not others. Some people hate the flat terse names of Phobos' modules. Does that mean those people are wrong? Does that mean Walter and Andrei are wrong? The only thing that is wrong here is deciding there is exactly one right rigid way to designate what should and should not be a property. I think we should have a definition of property convention for Phobos, but I don't think it needs to be the *only* way people use properties in their own projects. In fact, it can't be because there is no english (or whatever language you use) interpreter in the compiler. -Steve
Jan 29 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-29 13:57:06 -0500, "Steven Schveighoffer" 
<schveiguy yahoo.com> said:

 You win because Steven's definition is not good enough. I said before  
 that we should have a authoritative definition. If we really can't  
 define how a property should be defined after some reflection, then you 
  really win.
Be careful here, don't give Andrei hard criteria for declaring victory ;)
"some reflection" is a hard criteria now? :-)
 But my larger point was that convention is convention, whether you use  
 parentheses to designate what a function does, or the symbol name 
 itself.   Deciding the convention is liable to suit some and not 
 others.  Some  people hate the flat terse names of Phobos' modules.  
 Does that mean those  people are wrong?  Does that mean Walter and 
 Andrei are wrong?  The only  thing that is wrong here is deciding there 
 is exactly one right rigid way  to designate what should and should not 
 be a property.
Andrei wanted a good enough guideline so I gave one to him. We need a guideline if we hope for some consistency. Hopefully this guideline will be used through Phobos and this will set the example.
 I think we should have a definition of property convention for Phobos, 
 but  I don't think it needs to be the *only* way people use properties 
 in their  own projects.  In fact, it can't be because there is no 
 english (or  whatever language you use) interpreter in the compiler.
If someone want to diverge from the guideline, then that's his choice. It's pretty much like operator overloading: you can use it the intended way, or you can build boost::spirit. It's not like the compiler will ever be able to enforce this kind of thing, so there'll always be room for abuse, if you feel like it. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 29 2010
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Fri, Jan 29, 2010 at 10:41 AM, Michel Fortin
<michel.fortin michelf.com> wrote:
 On 2010-01-29 12:56:43 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:

 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 12:23:24 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Consider:

 struct Stack(T) {
 =A0 =A0 T pop();
 =A0 =A0 ...
 }

 By your definition, pop() should be a property. It doesn't quite strik=
e
 me as an intuitive decision.
is pop's main purpose to fetch a value or to modify the stack? =A0I'd s=
ay
 the purpose is split equally, so it's not a function whose main purpose=
is
 to fetch a value.
So now we're down to proportions, nuance, and where "main" goes. You mad=
e
 my point. I win.
You win because Steven's definition is not good enough. I said before tha=
t
 we should have a authoritative definition. If we really can't define how =
a
 property should be defined after some reflection, then you really win.

 My definition is that a property gives access to an aspect of an object a=
nd
 doesn't modify it (the getter is essentially logical-const). In this case=
,
 'pop' doesn't give you access to something in the stack, it removes an
 element (that's an action) and give you the element. It's pretty clear th=
at
 'pop' is used as a verb here, that should be enough to decide it's a
 function.
One more example to consider: RNG.randomInt() or RNG.randomInt I think Steven is right that you can always find corner cases, but that the existence of corner cases is pretty irrelevant. --bb
Jan 29 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 One more example to consider:  RNG.randomInt()  or RNG.randomInt
 
 I think Steven is right that you can always find corner cases, but
 that the existence of corner cases is pretty irrelevant.
I agree. It's not the existence of corner cases I'm worried about, it's the frequency. Andrei
Jan 29 2010
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 How is f.byLine clearer and less ambiguous than f.byLine()? Or vice 
 versa for that matter?
Note that properties can be named things other than byLine. -Steve
What I meant to say is that in the property landscape the following two conventions become suddenly attractive: * Do not use property at all * Use property for all nullary functions And they're bound to save a lot of time to everyone involved.
The first post of this thread was about not invoking a function when you don't want it to be invoked. bearophile was doing: auto dg = int function() { ... }; return dg; but he wanted to return a reference to dg, not the result of invoking it. One way to prevent that is to never invoke functions unless they are marked with property. Or maybe functions defined like that (closures, whatever) should always require () to be invoked. If that doesn't sound reasonable, see this: auto dg1 = int function() { ... }; auto dg2 = dg1; I'd expect dg2's type to be dg1's type. Let's just think a solution to this problem first. :-)
Jan 29 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 How is f.byLine clearer and less ambiguous than f.byLine()? Or vice 
 versa for that matter?
Note that properties can be named things other than byLine. -Steve
What I meant to say is that in the property landscape the following two conventions become suddenly attractive: * Do not use property at all * Use property for all nullary functions And they're bound to save a lot of time to everyone involved.
The first post of this thread was about not invoking a function when you don't want it to be invoked. bearophile was doing: auto dg = int function() { ... }; return dg; but he wanted to return a reference to dg, not the result of invoking it. One way to prevent that is to never invoke functions unless they are marked with property. Or maybe functions defined like that (closures, whatever) should always require () to be invoked. If that doesn't sound reasonable, see this: auto dg1 = int function() { ... }; auto dg2 = dg1; I'd expect dg2's type to be dg1's type. Let's just think a solution to this problem first. :-)
Correct. Just that I fear that it's a bit late for this all. It is disheartening enough that Walter got convinced by the past discussion and introduced property without much design - after a FAILED vote no less. I strongly believe a better solution is available, but everyone wanted the feature so the feature just got born. FWIW, my take for issues like the above: if a function returns a function or a delegate, it can't avail itself of automatic invocation of "()". That takes care of a corner case and keeps the mainstream case in good shape. I am not sure of a good solution for problems like writeln = 2; Andrei
Jan 29 2010
next sibling parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/29/2010 06:19 PM, Andrei Alexandrescu wrote:
 Ary Borenszweig wrote:
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 How is f.byLine clearer and less ambiguous than f.byLine()? Or vice
 versa for that matter?
Note that properties can be named things other than byLine. -Steve
What I meant to say is that in the property landscape the following two conventions become suddenly attractive: * Do not use property at all * Use property for all nullary functions And they're bound to save a lot of time to everyone involved.
The first post of this thread was about not invoking a function when you don't want it to be invoked. bearophile was doing: auto dg = int function() { ... }; return dg; but he wanted to return a reference to dg, not the result of invoking it. One way to prevent that is to never invoke functions unless they are marked with property. Or maybe functions defined like that (closures, whatever) should always require () to be invoked. If that doesn't sound reasonable, see this: auto dg1 = int function() { ... }; auto dg2 = dg1; I'd expect dg2's type to be dg1's type. Let's just think a solution to this problem first. :-)
Correct. Just that I fear that it's a bit late for this all. It is disheartening enough that Walter got convinced by the past discussion and introduced property without much design - after a FAILED vote no less. I strongly believe a better solution is available, but everyone wanted the feature so the feature just got born. FWIW, my take for issues like the above: if a function returns a function or a delegate, it can't avail itself of automatic invocation of "()". That takes care of a corner case and keeps the mainstream case in good shape. I am not sure of a good solution for problems like writeln = 2; Andrei
How about property? When you add a property to a function it can be called as an assignment. property does not touch the calling of no-argument functions. Are there any problems with that?
Jan 29 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Pelle MÃ¥nsson wrote:
 On 01/29/2010 06:19 PM, Andrei Alexandrescu wrote:
 Ary Borenszweig wrote:
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 How is f.byLine clearer and less ambiguous than f.byLine()? Or vice
 versa for that matter?
Note that properties can be named things other than byLine. -Steve
What I meant to say is that in the property landscape the following two conventions become suddenly attractive: * Do not use property at all * Use property for all nullary functions And they're bound to save a lot of time to everyone involved.
The first post of this thread was about not invoking a function when you don't want it to be invoked. bearophile was doing: auto dg = int function() { ... }; return dg; but he wanted to return a reference to dg, not the result of invoking it. One way to prevent that is to never invoke functions unless they are marked with property. Or maybe functions defined like that (closures, whatever) should always require () to be invoked. If that doesn't sound reasonable, see this: auto dg1 = int function() { ... }; auto dg2 = dg1; I'd expect dg2's type to be dg1's type. Let's just think a solution to this problem first. :-)
Correct. Just that I fear that it's a bit late for this all. It is disheartening enough that Walter got convinced by the past discussion and introduced property without much design - after a FAILED vote no less. I strongly believe a better solution is available, but everyone wanted the feature so the feature just got born. FWIW, my take for issues like the above: if a function returns a function or a delegate, it can't avail itself of automatic invocation of "()". That takes care of a corner case and keeps the mainstream case in good shape. I am not sure of a good solution for problems like writeln = 2; Andrei
How about property? When you add a property to a function it can be called as an assignment. property does not touch the calling of no-argument functions. Are there any problems with that?
Such a " property is just for the writing" design will leave property adepts very unhappy, I think. Even I admit that such a rule will be very inconsistent, albeit workable. Andrei
Jan 29 2010
parent Lutger <lutger.blijdestijn gmail.com> writes:
On 01/29/2010 07:01 PM, Andrei Alexandrescu wrote:
...
 How about  property? When you add a  property to a function it can be
 called as an assignment.  property does not touch the calling of
 no-argument functions.

 Are there any problems with that?
Such a " property is just for the writing" design will leave property adepts very unhappy, I think. Even I admit that such a rule will be very inconsistent, albeit workable. Andrei
It's not inconsistent, at most just a bit confusing on the call site. What property does is still very clear: - same syntax as fields for zero and one parameter functions - function call syntax *not* ok - mangled differently and recognizable by ide's (think gui programmming and ui design tools) and documentation tools. Probably also for metaprogramming. Additionally at the call site you can choose to drop parens for zero argument functions, author of those functions has no control over that. This feature is now orthogonal to property and may or may not end up in style guidelines. It's also one of those things a smart IDE could help you with (did the author really want this to be a property or not?) I think that solves most of the issues property was designed for.
Jan 29 2010
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:
 Ary Borenszweig wrote:
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 How is f.byLine clearer and less ambiguous than f.byLine()? Or vice 
 versa for that matter?
Note that properties can be named things other than byLine. -Steve
What I meant to say is that in the property landscape the following two conventions become suddenly attractive: * Do not use property at all * Use property for all nullary functions And they're bound to save a lot of time to everyone involved.
The first post of this thread was about not invoking a function when you don't want it to be invoked. bearophile was doing: auto dg = int function() { ... }; return dg; but he wanted to return a reference to dg, not the result of invoking it. One way to prevent that is to never invoke functions unless they are marked with property. Or maybe functions defined like that (closures, whatever) should always require () to be invoked. If that doesn't sound reasonable, see this: auto dg1 = int function() { ... }; auto dg2 = dg1; I'd expect dg2's type to be dg1's type. Let's just think a solution to this problem first. :-)
Correct. Just that I fear that it's a bit late for this all. It is disheartening enough that Walter got convinced by the past discussion and introduced property without much design - after a FAILED vote no less. I strongly believe a better solution is available, but everyone wanted the feature so the feature just got born. FWIW, my take for issues like the above: if a function returns a function or a delegate, it can't avail itself of automatic invocation of "()". That takes care of a corner case and keeps the mainstream case in good shape. I am not sure of a good solution for problems like writeln = 2;
I think at least for the function/delegate problem, requiring () to invoke it might be good. int foo() { ... } auto dg1 = bool function() { ... }; auto x = dg1; // x is bool function() auto y = dg1(); // y is bool auto dg2 = &foo; auto z = dg2; // z is int function() auto w = dg2(); // z is int The only thing that remains "problematic" is this one: auto dg3 = foo; // It's int. To take the address use & // but might lead to unexpected results // when using "auto"
Jan 29 2010
parent =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/29/2010 07:23 PM, Ary Borenszweig wrote:
 Andrei Alexandrescu wrote:
 Ary Borenszweig wrote:
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 How is f.byLine clearer and less ambiguous than f.byLine()? Or
 vice versa for that matter?
Note that properties can be named things other than byLine. -Steve
What I meant to say is that in the property landscape the following two conventions become suddenly attractive: * Do not use property at all * Use property for all nullary functions And they're bound to save a lot of time to everyone involved.
The first post of this thread was about not invoking a function when you don't want it to be invoked. bearophile was doing: auto dg = int function() { ... }; return dg; but he wanted to return a reference to dg, not the result of invoking it. One way to prevent that is to never invoke functions unless they are marked with property. Or maybe functions defined like that (closures, whatever) should always require () to be invoked. If that doesn't sound reasonable, see this: auto dg1 = int function() { ... }; auto dg2 = dg1; I'd expect dg2's type to be dg1's type. Let's just think a solution to this problem first. :-)
Correct. Just that I fear that it's a bit late for this all. It is disheartening enough that Walter got convinced by the past discussion and introduced property without much design - after a FAILED vote no less. I strongly believe a better solution is available, but everyone wanted the feature so the feature just got born. FWIW, my take for issues like the above: if a function returns a function or a delegate, it can't avail itself of automatic invocation of "()". That takes care of a corner case and keeps the mainstream case in good shape. I am not sure of a good solution for problems like writeln = 2;
I think at least for the function/delegate problem, requiring () to invoke it might be good. int foo() { ... } auto dg1 = bool function() { ... }; auto x = dg1; // x is bool function() auto y = dg1(); // y is bool auto dg2 = &foo; auto z = dg2; // z is int function() auto w = dg2(); // z is int The only thing that remains "problematic" is this one: auto dg3 = foo; // It's int. To take the address use & // but might lead to unexpected results // when using "auto"
If () is required to invoke delegates, that isn't a problem. First use will tell on it.
Jan 29 2010
prev sibling parent reply Justin Johansson <no spam.com> writes:
Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 How is f.byLine clearer and less ambiguous than f.byLine()? Or vice 
 versa for that matter?
Note that properties can be named things other than byLine. -Steve
What I meant to say is that in the property landscape the following two conventions become suddenly attractive: * Do not use property at all * Use property for all nullary functions And they're bound to save a lot of time to everyone involved. Andrei
Unless you assume no global state, nullary functions are just a figment of your imagination. Justin
Jan 29 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Justin Johansson wrote:
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 How is f.byLine clearer and less ambiguous than f.byLine()? Or vice 
 versa for that matter?
Note that properties can be named things other than byLine. -Steve
What I meant to say is that in the property landscape the following two conventions become suddenly attractive: * Do not use property at all * Use property for all nullary functions And they're bound to save a lot of time to everyone involved. Andrei
Unless you assume no global state, nullary functions are just a figment of your imagination.
Huh? What? Is there an extra "no"? Andrei
Jan 29 2010
parent Justin Johansson <no spam.com> writes:
Andrei Alexandrescu wrote:
 Justin Johansson wrote:
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:21:28 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 How is f.byLine clearer and less ambiguous than f.byLine()? Or vice 
 versa for that matter?
Note that properties can be named things other than byLine. -Steve
What I meant to say is that in the property landscape the following two conventions become suddenly attractive: * Do not use property at all * Use property for all nullary functions And they're bound to save a lot of time to everyone involved. Andrei
Unless you assume no global state, nullary functions are just a figment of your imagination.
Huh? What? Is there an extra "no"? Andrei
No, correct as I meant it. Confusion arises depending on whether you have a syntactic or semantic definition of "nullary" and / or FP or non-FP viewpoint. Some would argue that a simple writeln() function is a nullary function. Syntactically it is but there is a hidden argument, namely stdout. So writeln() is semantically non-nullary and may even be thought of as being declared by way of a macro expanded as fwriteln( FILE* fp = stdout). So unless the assumption is that there is no global state (including stdout in this case), thinking of writeln() as a nullary function is just a figment of one's imagination (imho) :-) It's a unary function with a default argument = stdout ! In the general case of a function, foo, taking N arguments where each argument is declared with a default value, e.g. foo( int a1 = 3, int a2 = 5, .. int aN = whatever), then called using all defaults as by foo(), or even just foo if optional dropping () is allowed, would people still argue that foo() with all default args is a nullary function? Just my two cents on nullary. -- Justin
Jan 29 2010
prev sibling parent reply Justin Johansson <no spam.com> writes:
Steven Schveighoffer wrote:
 
 We need digitalmars.D.is_it_a_property_or_not. Whenever in doubt, 
 people can ask a question there.
OK: digitalmars.d.should_this_be_a_class_or_struct. digitalmars.d.should_this_symbol_be_capitalized. digitalmars.d.should_this_use_a_function_pointer_or_delegate. digitalmars.d.should_this_be_const_or_immutable. Can we ever get any work done without these? -Steve
Closer to the mark would be ... digitalmars.d1.dont_ask digitalmars.d2.should_this_be_a_class_or_struct digitalmars.d2.should_this_symbol_be_capitalized digitalmars.d2.should_this_use_a_function_pointer_or_delegate digitalmars.d2.should_this_be_const_or_immutable digitalmars.d2.will_shared_ever_work Justin
Jan 29 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-29 11:47:17 -0500, Justin Johansson <no spam.com> said:

 Closer to the mark would be ...
 
 digitalmars.d1.dont_ask
 digitalmars.d2.should_this_be_a_class_or_struct
 digitalmars.d2.should_this_symbol_be_capitalized
 digitalmars.d2.should_this_use_a_function_pointer_or_delegate
 digitalmars.d2.should_this_be_const_or_immutable
 digitalmars.d2.will_shared_ever_work
 
 Justin
Also digitalmars.d.should_we_make_a_new_forum_for_this -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 29 2010
parent Justin Johansson <no spam.com> writes:
Michel Fortin wrote:
 On 2010-01-29 11:47:17 -0500, Justin Johansson <no spam.com> said:
 
 Closer to the mark would be ...

 digitalmars.d1.dont_ask
 digitalmars.d2.should_this_be_a_class_or_struct
 digitalmars.d2.should_this_symbol_be_capitalized
 digitalmars.d2.should_this_use_a_function_pointer_or_delegate
 digitalmars.d2.should_this_be_const_or_immutable
 digitalmars.d2.will_shared_ever_work

 Justin
Also digitalmars.d.should_we_make_a_new_forum_for_this
We could just join in over at scala.org.what_is_the_difference_between_var_val_and_def_keywords bit the ensuring discussion would not be as friendly. Justin
Jan 29 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-29 10:40:23 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 I'll tell you what I'd have liked: a landslide of responses to my 
 question revealing my mistaken ways and clarifying without a shade of a 
 doubt that byLine should be a  property. Or not. (I don't even care 
 which.)
 
 The fact we're having a debate about this (and Steve even says it's a 
 clear cut case and there are other more ambiguous!) is worrisome. Take 
 this: I got different answers from _supporters_ of  property!
The problem entirely reside on the ambiguous semantics of 'byLine'. The name makes us think it does something while it does something else (consuming a line). If it did what we'd expect it should be a property, but since it does not it shouldn't be. Fix 'byLine', either by changing the name or changing what it does, and whether it's a property or not will become clear.
 A good convention is one that you apply without wasting time to think 
 of it every single time you use it: naming conventions, braces 
 conventions, even most class vs. struct conventions. The well-defined 
 ones work great because _they save you time_.
Well, you should probably care a little more about your naming convention. It's confusing, and it'll probably end up waisting the time of some people who'll wonder why it consumes lines before you read them. I was absolutely sure it didn't before someone pointed it out to me. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 29 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 On 2010-01-29 10:40:23 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 I'll tell you what I'd have liked: a landslide of responses to my 
 question revealing my mistaken ways and clarifying without a shade of 
 a doubt that byLine should be a  property. Or not. (I don't even care 
 which.)

 The fact we're having a debate about this (and Steve even says it's a 
 clear cut case and there are other more ambiguous!) is worrisome. Take 
 this: I got different answers from _supporters_ of  property!
The problem entirely reside on the ambiguous semantics of 'byLine'. The name makes us think it does something while it does something else (consuming a line). If it did what we'd expect it should be a property, but since it does not it shouldn't be. Fix 'byLine', either by changing the name or changing what it does, and whether it's a property or not will become clear.
 A good convention is one that you apply without wasting time to think 
 of it every single time you use it: naming conventions, braces 
 conventions, even most class vs. struct conventions. The well-defined 
 ones work great because _they save you time_.
Well, you should probably care a little more about your naming convention. It's confusing, and it'll probably end up waisting the time of some people who'll wonder why it consumes lines before you read them. I was absolutely sure it didn't before someone pointed it out to me.
That's an implementation problem of byLine, not a issue with the byLine name. Andrei
Jan 29 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-29 11:19:32 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 That's an implementation problem of byLine, not a issue with the byLine name.
Ok, so if you agree that 'byLine' eating a line on creation is a bug, that means you don't expect 'byLine' to eat a line. That makes 'byLine' a property since calling the accessor doesn't (theoretically) modify the underlying object, it just provides access to an aspect of that object. Now it seems Steven and I both agree that it's a property. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 29 2010
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Michel Fortin wrote:
 On 2010-01-29 10:40:23 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 I'll tell you what I'd have liked: a landslide of responses to my 
 question revealing my mistaken ways and clarifying without a shade of 
 a doubt that byLine should be a  property. Or not. (I don't even care 
 which.)

 The fact we're having a debate about this (and Steve even says it's a 
 clear cut case and there are other more ambiguous!) is worrisome. Take 
 this: I got different answers from _supporters_ of  property!
The problem entirely reside on the ambiguous semantics of 'byLine'. The name makes us think it does something while it does something else (consuming a line). If it did what we'd expect it should be a property, but since it does not it shouldn't be. Fix 'byLine', either by changing the name or changing what it does, and whether it's a property or not will become clear.
This is a very good point! Using byLine as an argument against property is just silly, as it is badly-named to begin with. The name itself doesn't really tell you what it does, you have to read the docs or see it in the context of a foreach to understand it. The omittable parentheses are not the problem here. A more descriptive name would be either of these, depending on how the function actually works: readByLine() // not a property lines // definitely a property byLinesRange // also definitely a property
 A good convention is one that you apply without wasting time to think 
 of it every single time you use it: naming conventions, braces 
 conventions, even most class vs. struct conventions. The well-defined 
 ones work great because _they save you time_.
Well, you should probably care a little more about your naming convention. It's confusing, and it'll probably end up waisting the time of some people who'll wonder why it consumes lines before you read them. I was absolutely sure it didn't before someone pointed it out to me.
Speaking of Andrei's naming convention; in the case of empty() there were a lot of protests to the name, because people couldn't tell whether it was a property or an action. The property annotation mends that. -Lars
Jan 29 2010
prev sibling parent Justin Johansson <no spam.com> writes:
Andrei Alexandrescu wrote:
 We need digitalmars.D.is_it_a_property_or_not. Whenever in doubt, people 
 can ask a question there.
 Andrei
Obviously that's a rhetorical suggestion by Andrei ... but maybe a good idea if all this silliness prevails. Justin
Jan 29 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 08:03:13 -0500, Michel Fortin 
 <michel.fortin michelf.com> wrote:
 
 On 2010-01-29 06:25:44 -0500, Pelle MÃ¥nsson <pelle.mansson gmail.com> 
 said:

 On 01/29/2010 05:48 AM, Michel Fortin wrote:
  No. Calling byLine doesn't change the stream. It returns a different
 view of stdin, which can be used to modify the stream, or not. I think
 it should be a property. If it was 'getNextLine' then it should be a
 function. As a proof, this doesn't have any effect:
  stdin.byLine;
It reads a line off stdin. Try it.
Ah, I see, you're right. Silly me for not trying. So it's not an accessor after all. The problem is that, even disregarding the property syntax, the name strongly suggests it's an accessor, but it has side effects, which it shouldn't. Either we change the name to something else, like 'consumeLines()', or we make it behave like an accessor. I'd go for the second option. The basic problem lies in the very basic definition of an input range. Due to its interface (popFront + front), an input range is forced to consume the its first element by its mere existence. I think constructing an input range shouldn't have side effects. It should be more symmetrical with an output range. It could have just one function, 'take' to get the next element, and now byLine could work correctly.
Hey, it's that dead horse again, let's beat it! Andrei and I and several others discussed this ad infinitum. You will never convince Andrei that his design is wrong :)
Which debate are you referring to?
 The truth is, the fact that byLine modifies stdin by its mere existence 
 proves to be inconsequential.  Nobody will fetch the byLine property 
 without using it.  It's still an accessor.
Yah, though I agree it's nicer to not prime the line in the constructor. Andrei
Jan 29 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 10:31:28 -0500, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 08:03:13 -0500, Michel Fortin  
 <michel.fortin michelf.com> wrote:

 On 2010-01-29 06:25:44 -0500, Pelle MÃ¥nsson <pelle.mansson gmail.com>  
 said:

 On 01/29/2010 05:48 AM, Michel Fortin wrote:
  No. Calling byLine doesn't change the stream. It returns a different
 view of stdin, which can be used to modify the stream, or not. I  
 think
 it should be a property. If it was 'getNextLine' then it should be a
 function. As a proof, this doesn't have any effect:
  stdin.byLine;
It reads a line off stdin. Try it.
Ah, I see, you're right. Silly me for not trying. So it's not an accessor after all. The problem is that, even disregarding the property syntax, the name strongly suggests it's an accessor, but it has side effects, which it shouldn't. Either we change the name to something else, like 'consumeLines()', or we make it behave like an accessor. I'd go for the second option. The basic problem lies in the very basic definition of an input range. Due to its interface (popFront + front), an input range is forced to consume the its first element by its mere existence. I think constructing an input range shouldn't have side effects. It should be more symmetrical with an output range. It could have just one function, 'take' to get the next element, and now byLine could work correctly.
Hey, it's that dead horse again, let's beat it! Andrei and I and several others discussed this ad infinitum. You will never convince Andrei that his design is wrong :)
Which debate are you referring to?
hm... let me dig it up. (unwillingly) http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=90971
 The truth is, the fact that byLine modifies stdin by its mere existence  
 proves to be inconsequential.  Nobody will fetch the byLine property  
 without using it.  It's still an accessor.
Yah, though I agree it's nicer to not prime the line in the constructor.
This would help, but you still have to be careful with streamed ranges. The valid point Michael brought up is the following: // fetch 3 lines: string[] consume(3, stdin.byLine); // now fill a buffer ubyte[] buffer; buffer = stdin.rawRead(buffer); E[] consume(E, R)(int count, R range) { E[] elements; foreach (i; 0..count) { elements ~= range.front; range.popFront(); } return elements; } Note the extra popFront. So the loop must be rewritten: if (count != 0) // base case, need special case for this { int i = 0; while(!range.empty) // he forgot this condition { elements ~= range.front; if(++i == count) break; range.popFront(); } } ugh... much simpler with a true stream-like range that supports what is natural for streams: for(int i = 0; i < count && !range.empty; i++) { elements ~= range.get(); } But of course, then this function doesn't work for other range types. I decided in that discussion long ago that stream ranges were going to suck. -Steve
Jan 29 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-29 10:49:34 -0500, "Steven Schveighoffer" 
<schveiguy yahoo.com> said:

 ugh... much simpler with a true stream-like range that supports what is 
  natural for streams:
 
 for(int i = 0; i < count && !range.empty; i++) {
     elements ~= range.get();
 }
 
 But of course, then this function doesn't work for other range types.  
 I  decided in that discussion long ago that stream ranges were going to 
 suck.
You can always define a generic take() like this: E take(R, E)(ref R range) { E element = range.front; range.popFront(); return element; } This will work for any forward range. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 29 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 10:53:50 -0500, Michel Fortin  
<michel.fortin michelf.com> wrote:

 On 2010-01-29 10:49:34 -0500, "Steven Schveighoffer"  
 <schveiguy yahoo.com> said:

 ugh... much simpler with a true stream-like range that supports what is  
  natural for streams:
  for(int i = 0; i < count && !range.empty; i++) {
     elements ~= range.get();
 }
  But of course, then this function doesn't work for other range types.   
 I  decided in that discussion long ago that stream ranges were going to  
 suck.
You can always define a generic take() like this: E take(R, E)(ref R range) { E element = range.front; range.popFront(); return element; } This will work for any forward range.
Except stream ranges. I don't get it... -Steve
Jan 29 2010
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-29 11:00:31 -0500, "Steven Schveighoffer" 
<schveiguy yahoo.com> said:

 On Fri, 29 Jan 2010 10:53:50 -0500, Michel Fortin  
 <michel.fortin michelf.com> wrote:
 
 On 2010-01-29 10:49:34 -0500, "Steven Schveighoffer"  
 <schveiguy yahoo.com> said:
 
 ugh... much simpler with a true stream-like range that supports what is 
   natural for streams:
  for(int i = 0; i < count && !range.empty; i++) {
     elements ~= range.get();
 }
  But of course, then this function doesn't work for other range types.  
  I  decided in that discussion long ago that stream ranges were going 
 to  suck.
You can always define a generic take() like this: E take(R, E)(ref R range) { E element = range.front; range.popFront(); return element; } This will work for any forward range.
Except stream ranges. I don't get it...
Hum, well I used 'take' while you defined 'get' as the basic function for stream ranges. They're the same thing. Rename 'take' for 'get', or the reverse, and all input ranges can work with the same 'get' or 'take' function. (Note: I use 'take' instead of 'get' because it seems clearer to me that it also removes the element from the range.) -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 29 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 11:08:37 -0500, Michel Fortin  
<michel.fortin michelf.com> wrote:

 On 2010-01-29 11:00:31 -0500, "Steven Schveighoffer"  
 <schveiguy yahoo.com> said:

 On Fri, 29 Jan 2010 10:53:50 -0500, Michel Fortin   
 <michel.fortin michelf.com> wrote:

 On 2010-01-29 10:49:34 -0500, "Steven Schveighoffer"   
 <schveiguy yahoo.com> said:

 ugh... much simpler with a true stream-like range that supports what  
 is   natural for streams:
  for(int i = 0; i < count && !range.empty; i++) {
     elements ~= range.get();
 }
  But of course, then this function doesn't work for other range  
 types.   I  decided in that discussion long ago that stream ranges  
 were going to  suck.
You can always define a generic take() like this: E take(R, E)(ref R range) { E element = range.front; range.popFront(); return element; } This will work for any forward range.
Except stream ranges. I don't get it...
Hum, well I used 'take' while you defined 'get' as the basic function for stream ranges. They're the same thing. Rename 'take' for 'get', or the reverse, and all input ranges can work with the same 'get' or 'take' function. (Note: I use 'take' instead of 'get' because it seems clearer to me that it also removes the element from the range.)
Oh, I get it now. Yes, you can define this (BTW, I agree take is better than get). Whether we will ever get x.fn() => fn(x) for ranges remains to be seen. Without that, you have boilerplate code in every forward range and beyond. The other possibility is to define an abstraction function like: E take(R, E)(ref R range) { static if(isForwardRange!(R)) { // repeat your code above } else return range.take(); } and then use take(r) whenever you need that capability. -Steve
Jan 29 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 10:53:50 -0500, Michel Fortin 
 <michel.fortin michelf.com> wrote:
 
 On 2010-01-29 10:49:34 -0500, "Steven Schveighoffer" 
 <schveiguy yahoo.com> said:

 ugh... much simpler with a true stream-like range that supports what 
 is  natural for streams:
  for(int i = 0; i < count && !range.empty; i++) {
     elements ~= range.get();
 }
  But of course, then this function doesn't work for other range 
 types.  I  decided in that discussion long ago that stream ranges 
 were going to suck.
You can always define a generic take() like this: E take(R, E)(ref R range) { E element = range.front; range.popFront(); return element; } This will work for any forward range.
Except stream ranges. I don't get it...
It should work for stream ranges if front() checks the "filled" flag and eats the next line if false, and popFront clears the "filled" flag. Andrei
Jan 29 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 11:18:46 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 10:53:50 -0500, Michel Fortin  
 <michel.fortin michelf.com> wrote:

 On 2010-01-29 10:49:34 -0500, "Steven Schveighoffer"  
 <schveiguy yahoo.com> said:

 ugh... much simpler with a true stream-like range that supports what  
 is  natural for streams:
  for(int i = 0; i < count && !range.empty; i++) {
     elements ~= range.get();
 }
  But of course, then this function doesn't work for other range  
 types.  I  decided in that discussion long ago that stream ranges  
 were going to suck.
You can always define a generic take() like this: E take(R, E)(ref R range) { E element = range.front; range.popFront(); return element; } This will work for any forward range.
Except stream ranges. I don't get it...
It should work for stream ranges if front() checks the "filled" flag and eats the next line if false, and popFront clears the "filled" flag.
That actually makes a lot of sense. I hope this fix goes in. -Steve
Jan 29 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 11:18:46 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 10:53:50 -0500, Michel Fortin 
 <michel.fortin michelf.com> wrote:

 On 2010-01-29 10:49:34 -0500, "Steven Schveighoffer" 
 <schveiguy yahoo.com> said:

 ugh... much simpler with a true stream-like range that supports 
 what is  natural for streams:
  for(int i = 0; i < count && !range.empty; i++) {
     elements ~= range.get();
 }
  But of course, then this function doesn't work for other range 
 types.  I  decided in that discussion long ago that stream ranges 
 were going to suck.
You can always define a generic take() like this: E take(R, E)(ref R range) { E element = range.front; range.popFront(); return element; } This will work for any forward range.
Except stream ranges. I don't get it...
It should work for stream ranges if front() checks the "filled" flag and eats the next line if false, and popFront clears the "filled" flag.
That actually makes a lot of sense. I hope this fix goes in.
http://d.puremagic.com/issues/show_bug.cgi?id=3752 Andrei
Jan 29 2010
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-29 11:18:46 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 It should work for stream ranges if front() checks the "filled" flag 
 and eats the next line if false, and popFront clears the "filled" flag.
So now you want the front to fetch from stdin on the first call? It's the same problem as 'byLine' eating the first line when you create it: neither one or the other should affect the stream. Take my example from before: // fetch 3 lines: string[] consume(3, stdin.byLine); // now fill a buffer ubyte[] buffer; buffer = stdin.rawRead(buffer); E[] consume(E, R)(int count, R range) { E[] elements; foreach (i; 0..count) { elements ~= range.front; range.popFront(); } return elements; } Now add a range.front just after the popFront(): E[] consume(E, R)(int count, R range) { E[] elements; foreach (i; 0..count) { elements ~= range.front; range.popFront(); E peakedElement = range.front; } return elements; } And suddenly you'll get the same problem. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 29 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 11:33:17 -0500, Michel Fortin  
<michel.fortin michelf.com> wrote:

 On 2010-01-29 11:18:46 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> said:

 It should work for stream ranges if front() checks the "filled" flag  
 and eats the next line if false, and popFront clears the "filled" flag.
So now you want the front to fetch from stdin on the first call? It's the same problem as 'byLine' eating the first line when you create it: neither one or the other should affect the stream.
No, you're reaching here :) What Andrei is doing is acknowledging that front has already performed the job of popFront. Because of the nature of streams, you cannot get the data from the stream, and leave it on the stream at the same time. It's just not feasible. What the solution Andrei came up with does is to make stream ranges behave as close as possible to forward ranges. That small inconsistency will not hurt you because most of the time you are not calling front for an element you don't intend to use. And even within that paradigm, you are even less likely to use the stream in another capacity. In other words, as the last usage of a range in an algorithm function, this: r.front; r.popFront(); is way more likely than: r.popFront() r.front; -Steve
Jan 29 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-29 11:54:41 -0500, "Steven Schveighoffer" 
<schveiguy yahoo.com> said:

 On Fri, 29 Jan 2010 11:33:17 -0500, Michel Fortin  
 <michel.fortin michelf.com> wrote:
 
 On 2010-01-29 11:18:46 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> said:
 
 It should work for stream ranges if front() checks the "filled" flag  
 and eats the next line if false, and popFront clears the "filled" flag.
So now you want the front to fetch from stdin on the first call? It's the same problem as 'byLine' eating the first line when you create it: neither one or the other should affect the stream.
No, you're reaching here :) What Andrei is doing is acknowledging that front has already performed the job of popFront. Because of the nature of streams, you cannot get the data from the stream, and leave it on the stream at the same time. It's just not feasible. What the solution Andrei came up with does is to make stream ranges behave as close as possible to forward ranges. That small inconsistency will not hurt you because most of the time you are not calling front for an element you don't intend to use. And even within that paradigm, you are even less likely to use the stream in another capacity.
"will not hurt because most of the time"... surely you meant "will not hurt most of the time because". You're acknowledging it's an inconsistency and that it'll hurt.
 In other words, as the last usage of a range in an algorithm function,  this:
 
 r.front;
 r.popFront();
 
 is way more likely than:
 
 r.popFront()
 r.front;
Yeah, it's less likely to be a problem. But "less likely to be a problem" does still does not make things reliable. Something reliable works all the time, or it just doesn't work and tells you. And I'd argue that it's very likely that an algorithm hits the problem, check this: skipEmptyLines(stdin.byLine); string line = stdin.readln; void skipEmptyLines(R)(R range) { while (!range.empty && range.front == "") range.popFront; } skipEmptyLine works right with ranges, but not with a stream. On the last loop, it calls range.front, which removes a line from the stream, and then say it's finished. The truth is that this algorithm doesn't work with streams as it relies on a buffer being available. But it still compiles, silently introducing a bogus behaviour. If byLine defined only a 'take' function, we wouldn't have this problem as skipEmptyLines wouldn't compile, forcing you to use some kind of buffered stream or another algorithm that works correctly with streams. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 29 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 Yeah, it's less likely to be a problem. But "less likely to be a 
 problem" does still does not make things reliable. Something reliable 
 works all the time, or it just doesn't work and tells you.
stream.front after stream.popFront works all the time and fetches a new line off the stream. Like Steve said, you can't at the same time fetch a line and leave it back in the stream. Andrei
Jan 29 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-29 12:21:18 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Michel Fortin wrote:
 Yeah, it's less likely to be a problem. But "less likely to be a 
 problem" does still does not make things reliable. Something reliable 
 works all the time, or it just doesn't work and tells you.
stream.front after stream.popFront works all the time and fetches a new line off the stream. Like Steve said, you can't at the same time fetch a line and leave it back in the stream.
The problem is that algorithms that depends on this will work with other ranges, but will fail silently when given a stream. In all seriousness, even Java streams are better modeled than this (although more limited by not having templates). The basic Java input stream doesn't have a 'front' byte, you can only read the next byte (or the few next bytes). If you need to rewind, there is a standard way, but most streams need to be wrapped in a buffered stream first to provide this capability. So in our case, if you need to add a one-byte or a one-line buffer for a filtering stream I think it should be done explicitly as it has side effects on the underlying stream. In Java you do this by composition, creating a buffered stream from another input stream when you need one. Doing this implicitly, and especially creating a separate buffer each time you create a new filtering range, is what makes the problem hard to follow. Making 'front' lazy fetching will help in many cases, but it'll never remove the problem entirely. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 29 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 On 2010-01-29 12:21:18 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 Michel Fortin wrote:
 Yeah, it's less likely to be a problem. But "less likely to be a 
 problem" does still does not make things reliable. Something reliable 
 works all the time, or it just doesn't work and tells you.
stream.front after stream.popFront works all the time and fetches a new line off the stream. Like Steve said, you can't at the same time fetch a line and leave it back in the stream.
The problem is that algorithms that depends on this will work with other ranges, but will fail silently when given a stream.
An algorithm can fail in many silent ways if it misuses the range interface. None of std.algorithm algorithms uses front naively.
 In all seriousness, even Java streams are better modeled than this 
 (although more limited by not having templates). The basic Java input 
 stream doesn't have a 'front' byte, you can only read the next byte (or 
 the few next bytes). If you need to rewind, there is a standard way, but 
 most streams need to be wrapped in a buffered stream first to provide 
 this capability.
Can you run a basic algorithm on a Java stream and on an array as well? Andrei
Jan 29 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-29 12:53:27 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 An algorithm can fail in many silent ways if it misuses the range 
 interface. None of std.algorithm algorithms uses front naively.
Easy to say. How did you verify that? The problem is very subtle: if you call front after popFront on something like byLine which adds a buffer on top of another range, it'll eat one or more element on the downstream range that will be lost if you dispose of the filtering range. It won't have any effect on algorithms using the filtering range in itself, only on those using both the filtering range and the downstream range in tandem. So basically, if you have an algorithm that calls front after popFront, that algorithm cannot be used reliably for ranges filtering a stream when that stream is also used directly, or used via other filtering ranges. There's no way to enforce that as it becomes the user's problem. Whereas if input ranges only define 'take', it's pretty easy for the compiler to tell you an algorithm needs a buffer, so you add an intermediary buffer range yourself and you're now aware of the consequences.
 Can you run a basic algorithm on a Java stream and on an array as well?
Java lacks templates, and thus lack compile-time duck typing and work only with bytes. But you could iterate on an array as if it was a stream: class ArrayStream { byte[] array; int pos; ArrayStream(byte[] array) { this.array = array; pos = 0; } int read() { if (pos > array.length) return -1; else return array[pos++]; } } I'm not trying to say that Java streams are superior to ranges, but they don't have unintended buffering issues. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 29 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 On 2010-01-29 12:53:27 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 An algorithm can fail in many silent ways if it misuses the range 
 interface. None of std.algorithm algorithms uses front naively.
Easy to say. How did you verify that?
It's simply a mistake I make very seldom if at all (I don't remember any instance). The range interface is narrow, and algorithms are always careful with how they use it.
 The problem is very subtle: if you call front after popFront on 
 something like byLine which adds a buffer on top of another range, it'll 
 eat one or more element on the downstream range that will be lost if you 
 dispose of the filtering range. It won't have any effect on algorithms 
 using the filtering range in itself, only on those using both the 
 filtering range and the downstream range in tandem.
Subtle problems could occur with a variety of other ranges if some algorithm messes them up.
 So basically, if you have an algorithm that calls front after popFront, 
 that algorithm cannot be used reliably for ranges filtering a stream 
 when that stream is also used directly, or used via other filtering 
 ranges. There's no way to enforce that as it becomes the user's problem.
 
 Whereas if input ranges only define 'take', it's pretty easy for the 
 compiler to tell you an algorithm needs a buffer, so you add an 
 intermediary buffer range yourself and you're now aware of the 
 consequences.
I like take (I actually called it getNext). There was just too much aggravation in defining and using that interface. I've literally lost nights over figuring it out, and couldn't. Searching for getNext on this group will reveal some of the issues. Andrei
Jan 29 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 On 2010-01-29 11:18:46 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 It should work for stream ranges if front() checks the "filled" flag 
 and eats the next line if false, and popFront clears the "filled" flag.
So now you want the front to fetch from stdin on the first call? It's the same problem as 'byLine' eating the first line when you create it: neither one or the other should affect the stream. Take my example from before: // fetch 3 lines: string[] consume(3, stdin.byLine); // now fill a buffer ubyte[] buffer; buffer = stdin.rawRead(buffer); E[] consume(E, R)(int count, R range) { E[] elements; foreach (i; 0..count) { elements ~= range.front; range.popFront(); } return elements; } Now add a range.front just after the popFront(): E[] consume(E, R)(int count, R range) { E[] elements; foreach (i; 0..count) { elements ~= range.front; range.popFront(); E peakedElement = range.front; } return elements; } And suddenly you'll get the same problem.
I think this is not a problem as much as an organic characteristic of streams. STL's input streams work the same. Andrei
Jan 29 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:hjtpb4$1t17$1 digitalmars.com...
 Andrei, you keep complaining it's a convention. It *is* a convention, 
 because only a convention can differentiate actions from accessors. 
 Ideally, we wouldn't need a special syntax: English words would be enough. 
 But as you know English words alone are often ambiguous.
It's more than just the existence of ambiguous english words. It's also that () vs no-() makes it far easier to tell at a mere glance whether or not you're looking at a function. Imagine scrolling through a big chunk of code in a language that lacks optional-parens (and doesn't do any of that Java-style "getFoo()" crap). Without even reading a word of it, you quite literally *see* "function, function, value, value, etc." But with optional-parens (or those awful Java-style accessors), that gets thrown out the window and code needs more direct examination just to get the same amount of info out of it.
Jan 29 2010
prev sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Andrei Alexandrescu wrote:

 I agree. So where's the consensus? Things seemed so clear when people
 were beaten with  property over their head.
If I read the TLP correctly, property seems not to be working correctly. property (or any other notation marking property getters/setters) should be enforced. Functions that have it must only be invoked using property syntax. Functions that don't have it must be called with parentheses. That's the whole point. To give the designer of the class control over how it is used. The problem is people blurring the line between what's supposed to be a function and what's supposed to be a property, by abusing property syntax to invoke actions without parentheses. In reality, I believe there's not only a clear line between the two intentions, there's a demilitarized zone. You just need to enforce it. You can't have your cake and eat it too. -- Michiel Helvensteijn
Jan 28 2010
parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/28/2010 11:23 PM, Michiel Helvensteijn wrote:
 Andrei Alexandrescu wrote:

 I agree. So where's the consensus? Things seemed so clear when people
 were beaten with  property over their head.
If I read the TLP correctly, property seems not to be working correctly. property (or any other notation marking property getters/setters) should be enforced. Functions that have it must only be invoked using property syntax. Functions that don't have it must be called with parentheses. That's the whole point. To give the designer of the class control over how it is used. The problem is people blurring the line between what's supposed to be a function and what's supposed to be a property, by abusing property syntax to invoke actions without parentheses. In reality, I believe there's not only a clear line between the two intentions, there's a demilitarized zone. You just need to enforce it. You can't have your cake and eat it too.
I don't understand what any of this would improve. Is the byLine example less readable without the ()? Is it more bug prone? The only thing achieved as I can see is that every class designer makes up his own rules about which functions are property and which are not. If this is somehow enforced, it will become a guessing game about how to call no-argument functions. For what?
Jan 28 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Pelle MÃ¥nsson wrote:
 On 01/28/2010 11:23 PM, Michiel Helvensteijn wrote:
 Andrei Alexandrescu wrote:

 I agree. So where's the consensus? Things seemed so clear when people
 were beaten with  property over their head.
If I read the TLP correctly, property seems not to be working correctly. property (or any other notation marking property getters/setters) should be enforced. Functions that have it must only be invoked using property syntax. Functions that don't have it must be called with parentheses. That's the whole point. To give the designer of the class control over how it is used. The problem is people blurring the line between what's supposed to be a function and what's supposed to be a property, by abusing property syntax to invoke actions without parentheses. In reality, I believe there's not only a clear line between the two intentions, there's a demilitarized zone. You just need to enforce it. You can't have your cake and eat it too.
I don't understand what any of this would improve. Is the byLine example less readable without the ()? Is it more bug prone? The only thing achieved as I can see is that every class designer makes up his own rules about which functions are property and which are not. If this is somehow enforced, it will become a guessing game about how to call no-argument functions. For what?
++ Andrei
Jan 28 2010
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Thu, Jan 28, 2010 at 2:49 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Pelle M=E5nsson wrote:
 On 01/28/2010 11:23 PM, Michiel Helvensteijn wrote:
 Andrei Alexandrescu wrote:

 I agree. So where's the consensus? Things seemed so clear when people
 were beaten with  property over their head.
If I read the TLP correctly, property seems not to be working correctl=
y.
  property (or any other notation marking property getters/setters) shou=
ld
 be
 enforced. Functions that have it must only be invoked using property
 syntax. Functions that don't have it must be called with parentheses.
 That's the whole point. To give the designer of the class control over
 how
 it is used.

 The problem is people blurring the line between what's supposed to be a
 function and what's supposed to be a property, by abusing property synt=
ax
 to invoke actions without parentheses.

 In reality, I believe there's not only a clear line between the two
 intentions, there's a demilitarized zone. You just need to enforce it.
 You
 can't have your cake and eat it too.
I don't understand what any of this would improve. Is the byLine example less readable without the ()? Is it more bug prone? The only thing achieved as I can see is that every class designer makes =
up
 his own rules about which functions are property and which are not. If t=
his
 is somehow enforced, it will become a guessing game about how to call
 no-argument functions. For what?
The "what" is the things listed in DIP4 (http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP4) Particularly these issues: int delegate() foo() { return delegate int(){ return 5; }; } // Is this an int or a delegate? auto x =3D foo(); // Is this a reference to foo, or a reference to the delegate returned by f= oo? auto y =3D &foo; --bb
Jan 28 2010
parent =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/29/2010 12:01 AM, Bill Baxter wrote:
 On Thu, Jan 28, 2010 at 2:49 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org>  wrote:
 Pelle M�nsson wrote:
 On 01/28/2010 11:23 PM, Michiel Helvensteijn wrote:
 Andrei Alexandrescu wrote:

 I agree. So where's the consensus? Things seemed so clear when people
 were beaten with  property over their head.
If I read the TLP correctly, property seems not to be working correctly. property (or any other notation marking property getters/setters) should be enforced. Functions that have it must only be invoked using property syntax. Functions that don't have it must be called with parentheses. That's the whole point. To give the designer of the class control over how it is used. The problem is people blurring the line between what's supposed to be a function and what's supposed to be a property, by abusing property syntax to invoke actions without parentheses. In reality, I believe there's not only a clear line between the two intentions, there's a demilitarized zone. You just need to enforce it. You can't have your cake and eat it too.
I don't understand what any of this would improve. Is the byLine example less readable without the ()? Is it more bug prone? The only thing achieved as I can see is that every class designer makes up his own rules about which functions are property and which are not. If this is somehow enforced, it will become a guessing game about how to call no-argument functions. For what?
The "what" is the things listed in DIP4 (http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP4) Particularly these issues: int delegate() foo() { return delegate int(){ return 5; }; } // Is this an int or a delegate? auto x = foo();
A delegate. Same as auto x = foo;
 // Is this a reference to foo, or a reference to the delegate returned by foo?
 auto y =&foo;
A reference to foo. I feel this is obvious. Maybe I am wrong.
Jan 29 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Pelle Månsson" <pelle.mansson gmail.com> wrote in message 
news:hjt46j$5qt$1 digitalmars.com...
 I don't understand what any of this would improve. Is the byLine example 
 less readable without the ()? Is it more bug prone?

 The only thing achieved as I can see is that every class designer makes up 
 his own rules about which functions are property and which are not. If 
 this is somehow enforced, it will become a guessing game about how to call 
 no-argument functions. For what?
Class "Foo" has member "bar". Is "bar" a member variable or a member function? Can you set it? Does it require arguments? You don't know, do you? It's a guessing game. To the caller, *properties are not functions*! I don't understand why we keep having to go in circles on this. They are data. Data, data, data. Not functions. Data. "Oh, but no, they're *implemented* as functions!" Who gives a crap? That's *implementation*. They're data. Data, data, data. With the proposal, if I use a class, that class has data and functions. Not "member variables, functions called with parens, and functions called without parens." Just data and functions. That's it. Data and functions. So if this is enforced, and you have a function, how do you call it? *With parens*! Why? Because it's a fucking function and functions are fucking something, you already know damn well if it's a function or data. Because if you don't know what the hell it is, you can't f***** make sensible use of it anyway.
Jan 28 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Pelle Månsson" <pelle.mansson gmail.com> wrote in message 
 news:hjt46j$5qt$1 digitalmars.com...
 I don't understand what any of this would improve. Is the byLine example 
 less readable without the ()? Is it more bug prone?

 The only thing achieved as I can see is that every class designer makes up 
 his own rules about which functions are property and which are not. If 
 this is somehow enforced, it will become a guessing game about how to call 
 no-argument functions. For what?
Class "Foo" has member "bar". Is "bar" a member variable or a member function? Can you set it? Does it require arguments? You don't know, do you? It's a guessing game. To the caller, *properties are not functions*! I don't understand why we keep having to go in circles on this. They are data. Data, data, data. Not functions. Data. "Oh, but no, they're *implemented* as functions!" Who gives a crap? That's *implementation*. They're data. Data, data, data. With the proposal, if I use a class, that class has data and functions. Not "member variables, functions called with parens, and functions called without parens." Just data and functions. That's it. Data and functions. So if this is enforced, and you have a function, how do you call it? *With parens*! Why? Because it's a fucking function and functions are fucking something, you already know damn well if it's a function or data. Because if you don't know what the hell it is, you can't f***** make sensible use of it anyway.
Relax, we're all on the same boat. Unfortunately, your view that it's all functions and data is simplistic - it works well only when we talk about returning simple data types. I, too, wish it were that simple. Andrei
Jan 28 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:hjtbjh$pbg$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Pelle Månsson" <pelle.mansson gmail.com> wrote in message 
 news:hjt46j$5qt$1 digitalmars.com...
 I don't understand what any of this would improve. Is the byLine example 
 less readable without the ()? Is it more bug prone?

 The only thing achieved as I can see is that every class designer makes 
 up his own rules about which functions are property and which are not. 
 If this is somehow enforced, it will become a guessing game about how to 
 call no-argument functions. For what?
Class "Foo" has member "bar". Is "bar" a member variable or a member function? Can you set it? Does it require arguments? You don't know, do you? It's a guessing game. To the caller, *properties are not functions*! I don't understand why we keep having to go in circles on this. They are data. Data, data, data. Not functions. Data. "Oh, but no, they're *implemented* as functions!" Who gives a crap? That's *implementation*. They're data. Data, data, data. With the proposal, if I use a class, that class has data and functions. Not "member variables, functions called with parens, and functions called without parens." Just data and functions. That's it. Data and functions. So if this is enforced, and you have a function, how do you call it? *With parens*! Why? Because it's a fucking function and functions are to use something, you already know damn well if it's a function or data. Because if you don't know what the hell it is, you can't f***** make sensible use of it anyway.
Relax, we're all on the same boat. Unfortunately, your view that it's all functions and data is simplistic - it works well only when we talk about returning simple data types. I, too, wish it were that simple.
The only catches in the idea of the caller seeing it as all data and functions are issues that are equally true regardless of whether properites So ok, strictly speaking, there's functions and then there's data that comes in two flavors. But that still does absolutely nothing to change my point that removing optional parens creates *no* guessing game that we don't already have because it's still functions (use parens) and data (regardless of what type of data, don't use parens).
Jan 28 2010
parent =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/29/2010 02:21 AM, Nick Sabalausky wrote:
 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:hjtbjh$pbg$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Pelle M�nsson"<pelle.mansson gmail.com>  wrote in message
 news:hjt46j$5qt$1 digitalmars.com...
 I don't understand what any of this would improve. Is the byLine example
 less readable without the ()? Is it more bug prone?

 The only thing achieved as I can see is that every class designer makes
 up his own rules about which functions are property and which are not.
 If this is somehow enforced, it will become a guessing game about how to
 call no-argument functions. For what?
Class "Foo" has member "bar". Is "bar" a member variable or a member function? Can you set it? Does it require arguments? You don't know, do you? It's a guessing game. To the caller, *properties are not functions*! I don't understand why we keep having to go in circles on this. They are data. Data, data, data. Not functions. Data. "Oh, but no, they're *implemented* as functions!" Who gives a crap? That's *implementation*. They're data. Data, data, data. With the proposal, if I use a class, that class has data and functions. Not "member variables, functions called with parens, and functions called without parens." Just data and functions. That's it. Data and functions. So if this is enforced, and you have a function, how do you call it? *With parens*! Why? Because it's a fucking function and functions are to use something, you already know damn well if it's a function or data. Because if you don't know what the hell it is, you can't f***** make sensible use of it anyway.
Relax, we're all on the same boat. Unfortunately, your view that it's all functions and data is simplistic - it works well only when we talk about returning simple data types. I, too, wish it were that simple.
The only catches in the idea of the caller seeing it as all data and functions are issues that are equally true regardless of whether properites So ok, strictly speaking, there's functions and then there's data that comes in two flavors. But that still does absolutely nothing to change my point that removing optional parens creates *no* guessing game that we don't already have because it's still functions (use parens) and data (regardless of what type of data, don't use parens).
I don't think this definition really works. byLine returns a range, so it's data? If it's changed to an opApply based loop, is it still data? Where is the line between a simple function returning data and just data? I think property can be used to change the assignment, but not how the "get"-part of the function is called.
Jan 29 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 28 Jan 2010 17:54:33 -0500, Pelle MÃ¥nsson  
<pelle.mansson gmail.com> wrote:

 On 01/28/2010 11:23 PM, Michiel Helvensteijn wrote:
 Andrei Alexandrescu wrote:

 I agree. So where's the consensus? Things seemed so clear when people
 were beaten with  property over their head.
If I read the TLP correctly, property seems not to be working correctly. property (or any other notation marking property getters/setters) should be enforced. Functions that have it must only be invoked using property syntax. Functions that don't have it must be called with parentheses. That's the whole point. To give the designer of the class control over how it is used. The problem is people blurring the line between what's supposed to be a function and what's supposed to be a property, by abusing property syntax to invoke actions without parentheses. In reality, I believe there's not only a clear line between the two intentions, there's a demilitarized zone. You just need to enforce it. You can't have your cake and eat it too.
I don't understand what any of this would improve. Is the byLine example less readable without the ()? Is it more bug prone? The only thing achieved as I can see is that every class designer makes up his own rules about which functions are property and which are not. If this is somehow enforced, it will become a guessing game about how to call no-argument functions. For what?
Just as every class designer makes up his own rules about naming functions. The parentheses are part of the name of a function. Whether in your view the parentheses have meaning or not is your opinion. But you should not be able to attach your own meaning to my functions. What if we allowed a feature where you could call functions with just an unambiguous prefix? so something like: stdin.by(); Is that ok with you? It's not unambiguous, is it just as easy to understand as using the full name? The fact that byLine is just as descriptive as byLine() makes no difference. It is not a quintessential example of ambiguity. It should be a property IMO because of what it does, but even if it's not, it's not ambiguous. There are other cases which are ambiguous. -Steve
Jan 29 2010
prev sibling parent Rainer Deyke <rainerd eldwood.com> writes:
Michiel Helvensteijn wrote:
 Ah, my bad. I was guessing. Still, returning a handle from a property that
 can change the state of the originating object is.. iffy.
I disagree. For example, I recently had to deal with tables. Each table has rows and columns. Removing a row removes a cell from each column. Removing a column removes a cell from each row. However, I wanted to deal with both the set of rows and the set of columns as generic sequences. My solution was something like this: struct Table { RowView rows(); ColumnView columns(); }; I think 'rows' and 'columns' are perfect candidates for properties. They are nouns, not verbs. They could reasonably be implemented as fields instead of functions. They are not actions. They are views into the containing Table. Aspects of the Table, if you will. Properties. -- Rainer Deyke - rainerd eldwood.com
Jan 29 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michiel Helvensteijn wrote:
 Andrei Alexandrescu wrote:
 
 foreach (line; stdin.byLine()) { ... }

 vs.

 foreach (line; stdin.byLine) { ... }

 How do I choose?
byLine is a property. It is fetching a range on stdin. -Steve
Damn. I was sure the answer will be different.
byLine() is a function. It changes the state of stdin. Calling it consecutively will in general result in different return values. If there were two guys: stdin.currentLine (property) and stdin.nextLine(), it would be a different story. A property should act very much like a field. The advantages of properties are that they can be derived (not have a one-to-one relation with a storage location) or can do some clever caching/memoizing/logging.
I agree, but I'll also note that I got contradictory opinions from different supporters of property. So now it looks all the more like a judgment call, which is exactly what I was worried in the first place.
 Omitting parentheses on an action just because you can is stupid. It
 actually makes the language less readable and less predictable. And all
 that for saving two keystrokes.
I found my code to be more readable and just as predictable with the current rule. And it's not about two keystrokes, it's about persistent and ubiquitous syntactic noise. Gosh, property does suck. I was afraid that'd be true. Andrei
Jan 28 2010
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
On 01/28/2010 11:05 PM, Andrei Alexandrescu wrote:
 Michiel Helvensteijn wrote:
 Andrei Alexandrescu wrote:

 foreach (line; stdin.byLine()) { ... }

 vs.

 foreach (line; stdin.byLine) { ... }

 How do I choose?
byLine is a property. It is fetching a range on stdin. -Steve
Damn. I was sure the answer will be different.
byLine() is a function. It changes the state of stdin. Calling it consecutively will in general result in different return values. If there were two guys: stdin.currentLine (property) and stdin.nextLine(), it would be a different story. A property should act very much like a field. The advantages of properties are that they can be derived (not have a one-to-one relation with a storage location) or can do some clever caching/memoizing/logging.
I agree, but I'll also note that I got contradictory opinions from different supporters of property. So now it looks all the more like a judgment call, which is exactly what I was worried in the first place.
 Omitting parentheses on an action just because you can is stupid. It
 actually makes the language less readable and less predictable. And all
 that for saving two keystrokes.
I found my code to be more readable and just as predictable with the current rule. And it's not about two keystrokes, it's about persistent and ubiquitous syntactic noise. Gosh, property does suck. I was afraid that'd be true. Andrei
Lot's of things are judgement calls, I don't see the problem. property is a tool like everything else, there are many more cases where it's pretty clear cut. The ambivalence here is inherent in the code, and only brought out by the property question, not caused by it. Notice there was also no consensus of what byLine actually did under the hood. Also, don't forget these: - property allows you to forbid the caller using parenthesis, there is no other way in D to achieve this for accessor functions - so far ignored in this thread: any kind of code inspection (reflection, compile time, by IDE) can use the ' property property' for various purposes.
Jan 28 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Lutger wrote:
 On 01/28/2010 11:05 PM, Andrei Alexandrescu wrote:
 Michiel Helvensteijn wrote:
 Andrei Alexandrescu wrote:

 foreach (line; stdin.byLine()) { ... }

 vs.

 foreach (line; stdin.byLine) { ... }

 How do I choose?
byLine is a property. It is fetching a range on stdin. -Steve
Damn. I was sure the answer will be different.
byLine() is a function. It changes the state of stdin. Calling it consecutively will in general result in different return values. If there were two guys: stdin.currentLine (property) and stdin.nextLine(), it would be a different story. A property should act very much like a field. The advantages of properties are that they can be derived (not have a one-to-one relation with a storage location) or can do some clever caching/memoizing/logging.
I agree, but I'll also note that I got contradictory opinions from different supporters of property. So now it looks all the more like a judgment call, which is exactly what I was worried in the first place.
 Omitting parentheses on an action just because you can is stupid. It
 actually makes the language less readable and less predictable. And all
 that for saving two keystrokes.
I found my code to be more readable and just as predictable with the current rule. And it's not about two keystrokes, it's about persistent and ubiquitous syntactic noise. Gosh, property does suck. I was afraid that'd be true. Andrei
Lot's of things are judgement calls, I don't see the problem. property is a tool like everything else, there are many more cases where it's pretty clear cut. The ambivalence here is inherent in the code, and only brought out by the property question, not caused by it. Notice there was also no consensus of what byLine actually did under the hood. Also, don't forget these: - property allows you to forbid the caller using parenthesis, there is no other way in D to achieve this for accessor functions - so far ignored in this thread: any kind of code inspection (reflection, compile time, by IDE) can use the ' property property' for various purposes.
Wise words. So how do I go about byLine? Andrei
Jan 28 2010
parent Lutger <lutger.blijdestijn gmail.com> writes:
On 01/28/2010 11:28 PM, Andrei Alexandrescu wrote:
 Lutger wrote:
 On 01/28/2010 11:05 PM, Andrei Alexandrescu wrote:
 Michiel Helvensteijn wrote:
 Andrei Alexandrescu wrote:

 foreach (line; stdin.byLine()) { ... }

 vs.

 foreach (line; stdin.byLine) { ... }

 How do I choose?
byLine is a property. It is fetching a range on stdin. -Steve
Damn. I was sure the answer will be different.
byLine() is a function. It changes the state of stdin. Calling it consecutively will in general result in different return values. If there were two guys: stdin.currentLine (property) and stdin.nextLine(), it would be a different story. A property should act very much like a field. The advantages of properties are that they can be derived (not have a one-to-one relation with a storage location) or can do some clever caching/memoizing/logging.
I agree, but I'll also note that I got contradictory opinions from different supporters of property. So now it looks all the more like a judgment call, which is exactly what I was worried in the first place.
 Omitting parentheses on an action just because you can is stupid. It
 actually makes the language less readable and less predictable. And all
 that for saving two keystrokes.
I found my code to be more readable and just as predictable with the current rule. And it's not about two keystrokes, it's about persistent and ubiquitous syntactic noise. Gosh, property does suck. I was afraid that'd be true. Andrei
Lot's of things are judgement calls, I don't see the problem. property is a tool like everything else, there are many more cases where it's pretty clear cut. The ambivalence here is inherent in the code, and only brought out by the property question, not caused by it. Notice there was also no consensus of what byLine actually did under the hood. Also, don't forget these: - property allows you to forbid the caller using parenthesis, there is no other way in D to achieve this for accessor functions - so far ignored in this thread: any kind of code inspection (reflection, compile time, by IDE) can use the ' property property' for various purposes.
Wise words. So how do I go about byLine? Andrei
You make a good judgement call :) this is possible right: auto iter = stdin.byLine; foreach(line; iter) ... could you imagine byLine as an abbreviation of byLineRange or getByLineRange a la Java? or even conceive of: stdin.byLine = aDifferentFlavorOfByLine? So yes, I'm inclined to think of it as a property.
Jan 28 2010
prev sibling parent torhu <no spam.invalid> writes:
On 28.01.2010 21:59, Andrei Alexandrescu wrote:
 How about this:

 foreach (line; stdin.byLine()) { ... }

 vs.

 foreach (line; stdin.byLine) { ... }

 How do I choose?
I'd say byLine as it's currently implemented in std.stdio is not a property. It initializes and returns a new ByLine struct each time it's called. It even has arguments that enables you to configure its return value differently each time you call it. Nowhere near how it would behave if it was a field. A property should at least return the same value if you call it several times in a row, without doing anything in between that you'd expect to alter the value. The fact that using byLine's return value changes the File itself doesn't change anything. That's a separate issue. Even if byLine was a field, using it would alter the underlying File.
Jan 30 2010
prev sibling parent retard <re tard.com.invalid> writes:
Wed, 27 Jan 2010 18:34:57 +0100, Pelle MÃ¥nsson wrote:

 I disagree, I find the function calls without the () to be really
 prettifying.
 
 But maybe that's just me.
 
 I don't think that it causes serious bugs, you would see that it's an
 integer the moment you try and use it. It also helps changing code
 from/to functions.
 
 I really like this feature, and would miss it should it go away.
I just can't understand why implementing the optional ()s can be so hard. Scala does it and as far as I know, the solution doesn't have any problems. They also solved the property issues. In scala property methods have special names to distinguish them. object foo { def prop = 42; def prop_=(a: Int) = println(a) } defined module foo scala> foo.prop = 42 42 scala> object foo { def prop = 42; def prop_=(a: Int) = println(a) } defined module foo scala> foo.prop res12: Int = 42 scala> foo.prop() <console>:6: error: foo.prop of type Int does not take parameters foo.prop() ^ scala> foo.prop = 42 42 scala> foo.prop(42) <console>:6: error: foo.prop of type Int does not take parameters foo.prop(42) ^ scala> foo.prop_(42) <console>:6: error: value prop_ is not a member of object foo foo.prop_(42) ^ scala> foo.prop_=(42) 42 scala> foo.prop += 1 43
Jan 28 2010
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
Andrei Alexandrescu Wrote:

 Michiel Helvensteijn wrote:
 Andrei Alexandrescu wrote:
 
 foreach (line; stdin.byLine()) { ... }

 vs.

 foreach (line; stdin.byLine) { ... }

 How do I choose?
byLine is a property. It is fetching a range on stdin. -Steve
Damn. I was sure the answer will be different.
byLine() is a function. It changes the state of stdin. Calling it consecutively will in general result in different return values. If there were two guys: stdin.currentLine (property) and stdin.nextLine(), it would be a different story.
No no no. byLine returns a struct, it does not modify stdin. Operating on the struct modifies stdin, but that is outside the call to the property getter. Look at it this way (although this is not the only way to look at it), could byLine be a field inside stdin? It could. You could store a copy of what byLine returns inside stdin, and people could just access it.
 A property should act very much like a field. The advantages of properties
 are that they can be derived (not have a one-to-one relation with a storage
 location) or can do some clever caching/memoizing/logging.
I agree, but I'll also note that I got contradictory opinions from different supporters of property. So now it looks all the more like a judgment call, which is exactly what I was worried in the first place.
There are some cases that are judgement calls and some that are obvious. byLine is obvious. The difference is that the *author* is making the judgement call, not the *user*. The difference is important, because when a user complains that your property is doing things a property shouldn't, and then you realize the "property" in question isn't even a property at all, your only solution (with the non-attributed system) is to tell the user not to use it that way. There is no way to get him to stop, or to get other users to stop. You have lost control over the semantic meaning of your function, even though you defined it and documented it. And yes, this did actually happen to me.
 
 Omitting parentheses on an action just because you can is stupid. It
 actually makes the language less readable and less predictable. And all
 that for saving two keystrokes.
I found my code to be more readable and just as predictable with the current rule. And it's not about two keystrokes, it's about persistent and ubiquitous syntactic noise. Gosh, property does suck. I was afraid that'd be true.
This is your opinion when reading *your* code. It doesn't suck if you value being able to read code written by *others*. -Steve
Jan 28 2010
next sibling parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/29/2010 05:20 AM, Steven Schveighoffer wrote:
 Look at it this way (although this is not the only way to look at it), could
byLine be a field inside stdin?  It could.  You could store a copy of what
byLine returns inside stdin, and people could just access it.
byLine modifies stdin. If you do this: auto a = stdin.byLine; You consume a line off stdin.
 There are some cases that are judgement calls and some that are obvious. 
byLine is obvious.
Apparently not.
 The difference is that the *author* is making the judgement call, not the
*user*.  The difference is important, because when a user complains that your
property is doing things a property shouldn't, and then you realize the
"property" in question isn't even a property at all, your only solution (with
the non-attributed system) is to tell the user not to use it that way.  There
is no way to get him to stop, or to get other users to stop.  You have lost
control over the semantic meaning of your function, even though you defined it
and documented it.

 And yes, this did actually happen to me.
Sounds like a naming issue to me. :)
Jan 29 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 06:16:15 -0500, Pelle MÃ¥nsson  
<pelle.mansson gmail.com> wrote:

 On 01/29/2010 05:20 AM, Steven Schveighoffer wrote:
 Look at it this way (although this is not the only way to look at it),  
 could byLine be a field inside stdin?  It could.  You could store a  
 copy of what byLine returns inside stdin, and people could just access  
 it.
byLine modifies stdin. If you do this: auto a = stdin.byLine; You consume a line off stdin.
That's a deficiency in the design of byLine. It's a range that "primes" itself with a line of text. The fact that you can enter the line above and just throw away the data seems error prone to me. When would you ever use that "feature"? In practice, it doesn't matter, because the only purpose to fetch the byLine struct is to iterate data from stdin. The design could be fixed with a boolean isPrimed that is unset on the first call to front. But like I said, it doesn't matter in the long run, since nobody ever fetches byLine without using it. I find that the shoehorning of an input range onto a stream is always going to have this problem, so there's not much we can do about it. It doesn't change the concept that byLine is a property. I find streams much better suited to opApply, but I've already had that unsuccessful battle, and I don't want to have it again.
 There are some cases that are judgement calls and some that are  
 obvious.  byLine is obvious.
Apparently not.
I don't see why you think it's not a property. It fetches a range from stdin, there is no other purpose. If you think byLine's purpose is to throw away a line of text, I think first that you are now attaching unintended semantic meaning to it (exactly what properties are meant to prevent) and second, I'd consider it to be a poorly named function. I guess someone should complain that it's not called popLine(), because as a function, that's what it does.
 The difference is that the *author* is making the judgement call, not  
 the *user*.  The difference is important, because when a user complains  
 that your property is doing things a property shouldn't, and then you  
 realize the "property" in question isn't even a property at all, your  
 only solution (with the non-attributed system) is to tell the user not  
 to use it that way.  There is no way to get him to stop, or to get  
 other users to stop.  You have lost control over the semantic meaning  
 of your function, even though you defined it and documented it.

 And yes, this did actually happen to me.
Sounds like a naming issue to me. :)
You be the judge: http://www.dsource.org/projects/tango/ticket/1184 I find the resulting workaround very unsavory. -Steve
Jan 29 2010
parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/29/2010 02:01 PM, Steven Schveighoffer wrote:
 That's a deficiency in the design of byLine. It's a range that "primes"
 itself with a line of text. The fact that you can enter the line above
 and just throw away the data seems error prone to me. When would you
 ever use that "feature"? In practice, it doesn't matter, because the
 only purpose to fetch the byLine struct is to iterate data from stdin.

 The design could be fixed with a boolean isPrimed that is unset on the
 first call to front. But like I said, it doesn't matter in the long run,
 since nobody ever fetches byLine without using it.

 I find that the shoehorning of an input range onto a stream is always
 going to have this problem, so there's not much we can do about it. It
 doesn't change the concept that byLine is a property. I find streams
 much better suited to opApply, but I've already had that unsuccessful
 battle, and I don't want to have it again.
So byLine should be a property when implemented as a range, and a function when implemented as an opApply based loop? I feel that is a problem.
 You be the judge: http://www.dsource.org/projects/tango/ticket/1184

 I find the resulting workaround very unsavory.

 -Steve
That's the assignment syntax, which I do agree is weird. Sorry if I was unclear. This is what I thought property was for. It has, however, nothing to do with the omitting of the ().
Jan 29 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 12:42:57 -0500, Pelle MÃ¥nsson  
<pelle.mansson gmail.com> wrote:

 On 01/29/2010 02:01 PM, Steven Schveighoffer wrote:
 That's a deficiency in the design of byLine. It's a range that "primes"
 itself with a line of text. The fact that you can enter the line above
 and just throw away the data seems error prone to me. When would you
 ever use that "feature"? In practice, it doesn't matter, because the
 only purpose to fetch the byLine struct is to iterate data from stdin.

 The design could be fixed with a boolean isPrimed that is unset on the
 first call to front. But like I said, it doesn't matter in the long run,
 since nobody ever fetches byLine without using it.

 I find that the shoehorning of an input range onto a stream is always
 going to have this problem, so there's not much we can do about it. It
 doesn't change the concept that byLine is a property. I find streams
 much better suited to opApply, but I've already had that unsuccessful
 battle, and I don't want to have it again.
So byLine should be a property when implemented as a range, and a function when implemented as an opApply based loop?
I meant byLine should return a struct that implements opApply. If it is a function then you have to pass the address to foreach, which is a little awkward.
 You be the judge: http://www.dsource.org/projects/tango/ticket/1184

 I find the resulting workaround very unsavory.

 -Steve
That's the assignment syntax, which I do agree is weird. Sorry if I was unclear. This is what I thought property was for. It has, however, nothing to do with the omitting of the ().
No, but it is an example of someone misinterpreting the meaning of a function because the compiler accepted his syntax. Yes, the assignment rewrite is more troublesome than the getter, but being able to force someone to omit the parentheses has its advantages: user1: When I call range.empty(), it doesn't clear the range developer: Hm.. empty is not an action, its a property. Maybe I'll fix it by changing it to isEmpty to make it clear. user1: great idea! that's much clearer. .... user2: Why did you name it isEmpty, isn't the 'is' redundant since this looks perfectly normal? if(r.empty) developer: *sigh* This is the problem I ran into. Because so much meaning is attached to the () by humans, you must resort to naming conventions to make the intentions clear, then point out the reasons for not using a better name to future complainers. Note in the anecdote above, both users would have been satisfied if you could *only* call empty without parentheses. The no-parens property requirement has nothing to do with compiler interpretation or functionality and everything to do with human interpretation. It's all about what does the call *look* like it's doing as opposed to what it actually does. By enforcing the removal of parentheses, most normal users don't have to read the docs or look at anything else. It just works the way it's supposed to work, and looks like it does that. This doesn't make every single case clear, nor does it install automatic wisdom in all developers to be able to invent intuitive names. What it does is make it *possible* for you to invent intuitive names that retain their meaning and are succinct. I don't know about you, but using libraries with intuitive, consistent, and succinct terminology is really much more enjoyable than ones with inconsistent or overly verbose terminology. The other benefit is it makes calling delegate properties less ugly and more consistent with analogous fields. -Steve
Jan 29 2010
parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/29/2010 07:10 PM, Steven Schveighoffer wrote:
 Note in the anecdote above, both users would have
 been satisfied if you could *only* call empty without parentheses.
That's a good point. The writeln = 3; is also a good point. :) What I'm trying to defend is the ability to call non-property functions without the parens. I find this: array.stable_sort; file.detach; range.popFront; to look less noisy, clearer and just plain sexier than the respective versions with the parens.
Jan 29 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 13:43:50 -0500, Pelle MÃ¥nsson  
<pelle.mansson gmail.com> wrote:

 On 01/29/2010 07:10 PM, Steven Schveighoffer wrote:
 Note in the anecdote above, both users would have
 been satisfied if you could *only* call empty without parentheses.
That's a good point. The writeln = 3; is also a good point. :) What I'm trying to defend is the ability to call non-property functions without the parens. I find this: array.stable_sort; file.detach; range.popFront; to look less noisy, clearer and just plain sexier than the respective versions with the parens.
You've cited three functions where the function names cannot be misinterpreted as properties. This is not the case for all function names. If you wish to have a way to specify a function can be called either way, then I think you also need a way to specify that a function can only be called with parentheses. I don't disagree that the above is unambiguous, but there are examples where it is ambiguous. f.read; does this mean read f, or is it an accidental noop fetching a property indicating f is read? Requiring parentheses also allows you to force meanings where they would otherwise be interpreted as properties: f.next(); Looks like it advances f, even though next isn't a verb. Without the parentheses, it looks like a noop access of a property. I'm not too concerned with requiring () on your examples because it's inconsequential to me -- having parentheses isn't *less* clear than not having them. I don't mind if you wish to allow these calls without parens, but there has to still be a way to force the parens. -Steve
Jan 29 2010
next sibling parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/29/2010 08:07 PM, Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 13:43:50 -0500, Pelle MÃ¥nsson
 <pelle.mansson gmail.com> wrote:

 On 01/29/2010 07:10 PM, Steven Schveighoffer wrote:
 Note in the anecdote above, both users would have
 been satisfied if you could *only* call empty without parentheses.
That's a good point. The writeln = 3; is also a good point. :) What I'm trying to defend is the ability to call non-property functions without the parens. I find this: array.stable_sort; file.detach; range.popFront; to look less noisy, clearer and just plain sexier than the respective versions with the parens.
You've cited three functions where the function names cannot be misinterpreted as properties. This is not the case for all function names. If you wish to have a way to specify a function can be called either way, then I think you also need a way to specify that a function can only be called with parentheses. I don't disagree that the above is unambiguous, but there are examples where it is ambiguous. f.read; does this mean read f, or is it an accidental noop fetching a property indicating f is read? Requiring parentheses also allows you to force meanings where they would otherwise be interpreted as properties: f.next(); Looks like it advances f, even though next isn't a verb. Without the parentheses, it looks like a noop access of a property.
I disagree, it doesn't look like it advances. With the parens, it just looks like a java-style get-function. To me, at least.
 I'm not too concerned with requiring () on your examples because it's
 inconsequential to me -- having parentheses isn't *less* clear than not
 having them. I don't mind if you wish to allow these calls without
 parens, but there has to still be a way to force the parens.

 -Steve
I disagree. I understand that in some cases we would not want to permit calling with parenthesis, and that calling as assignment is sometimes less than ideal. I do not, however, see any reason to allow forcing of parenthesis for regular functions.
Jan 29 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 29 Jan 2010 14:23:55 -0500, Pelle MÃ¥nsson  
<pelle.mansson gmail.com> wrote:

 On 01/29/2010 08:07 PM, Steven Schveighoffer wrote:
 f.next();

 Looks like it advances f, even though next isn't a verb. Without the
 parentheses, it looks like a noop access of a property.
I disagree, it doesn't look like it advances. With the parens, it just looks like a java-style get-function. To me, at least.
If this were Java, I'd agree with you :) But even on Java, it would have to be getNext().
 I'm not too concerned with requiring () on your examples because it's
 inconsequential to me -- having parentheses isn't *less* clear than not
 having them. I don't mind if you wish to allow these calls without
 parens, but there has to still be a way to force the parens.
I disagree. I understand that in some cases we would not want to permit calling with parenthesis, and that calling as assignment is sometimes less than ideal. I do not, however, see any reason to allow forcing of parenthesis for regular functions.
I guess D can't please everybody all the time. Oh well. -Steve
Jan 29 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 13:43:50 -0500, Pelle MÃ¥nsson 
 <pelle.mansson gmail.com> wrote:
 
 On 01/29/2010 07:10 PM, Steven Schveighoffer wrote:
 Note in the anecdote above, both users would have
 been satisfied if you could *only* call empty without parentheses.
That's a good point. The writeln = 3; is also a good point. :) What I'm trying to defend is the ability to call non-property functions without the parens. I find this: array.stable_sort; file.detach; range.popFront; to look less noisy, clearer and just plain sexier than the respective versions with the parens.
You've cited three functions where the function names cannot be misinterpreted as properties. This is not the case for all function names. If you wish to have a way to specify a function can be called either way, then I think you also need a way to specify that a function can only be called with parentheses. I don't disagree that the above is unambiguous, but there are examples where it is ambiguous. f.read; does this mean read f, or is it an accidental noop fetching a property indicating f is read?
"Rules are not meant to be followed robotically." Sorry I couldn't abstain :o).
 Requiring parentheses also allows you to force meanings where they would 
 otherwise be interpreted as properties:
 
 f.next();
 
 Looks like it advances f, even though next isn't a verb.  Without the 
 parentheses, it looks like a noop access of a property.
 
 I'm not too concerned with requiring () on your examples because it's 
 inconsequential to me -- having parentheses isn't *less* clear than not 
 having them.  I don't mind if you wish to allow these calls without 
 parens, but there has to still be a way to force the parens.
 
 -Steve
Ok how about this: if just calling the thing changes the parent, it can't be a property. Guess I could live with that. Andrei
Jan 29 2010
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Jan 29, 2010 at 12:02 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Steven Schveighoffer wrote:
 On Fri, 29 Jan 2010 13:43:50 -0500, Pelle M=E5nsson
 <pelle.mansson gmail.com> wrote:

 On 01/29/2010 07:10 PM, Steven Schveighoffer wrote:
 Note in the anecdote above, both users would have
 been satisfied if you could *only* call empty without parentheses.
That's a good point. The writeln =3D 3; is also a good point. :) What I'm trying to defend is the ability to call non-property functions without the parens. I find this: array.stable_sort; file.detach; range.popFront; to look less noisy, clearer and just plain sexier than the respective versions with the parens.
You've cited three functions where the function names cannot be misinterpreted as properties. =A0This is not the case for all function n=
ames.
 =A0If you wish to have a way to specify a function can be called either =
way,
 then I think you also need a way to specify that a function can only be
 called with parentheses.

 I don't disagree that the above is unambiguous, but there are examples
 where it is ambiguous.

 f.read;

 does this mean read f, or is it an accidental noop fetching a property
 indicating f is read?
"Rules are not meant to be followed robotically." Sorry I couldn't abstain :o).
 Requiring parentheses also allows you to force meanings where they would
 otherwise be interpreted as properties:

 f.next();

 Looks like it advances f, even though next isn't a verb. =A0Without the
 parentheses, it looks like a noop access of a property.

 I'm not too concerned with requiring () on your examples because it's
 inconsequential to me -- having parentheses isn't *less* clear than not
 having them. =A0I don't mind if you wish to allow these calls without pa=
rens,
 but there has to still be a way to force the parens.

 -Steve
Ok how about this: if just calling the thing changes the parent, it can't=
be
 a property. Guess I could live with that.
Should be "if calling the thing changes the parent in an outwardly visible way". Doing refcounting or caching mutations under the hood should be ok. --bb
Jan 29 2010
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-29 15:02:13 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Ok how about this: if just calling the thing changes the parent, it 
 can't be a property. Guess I could live with that.
Hopefully that rule will only apply to the getter. :-) -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 29 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Pelle Månsson" <pelle.mansson gmail.com> wrote in message 
news:hjv9sf$1n5o$1 digitalmars.com...
 On 01/29/2010 07:10 PM, Steven Schveighoffer wrote:
 Note in the anecdote above, both users would have
 been satisfied if you could *only* call empty without parentheses.
That's a good point. The writeln = 3; is also a good point. :) What I'm trying to defend is the ability to call non-property functions without the parens. I find this: array.stable_sort; file.detach; range.popFront; to look less noisy, clearer and just plain sexier than the respective versions with the parens.
To me, at a glance, it looks like a series of no-ops. Like "x; y; z;". Only upon closer inspection of the names does it become apperent that functions are actually being called.
Jan 29 2010
parent reply Don <nospam nospam.com> writes:
Nick Sabalausky wrote:
 "Pelle Månsson" <pelle.mansson gmail.com> wrote in message 
 news:hjv9sf$1n5o$1 digitalmars.com...
 On 01/29/2010 07:10 PM, Steven Schveighoffer wrote:
 Note in the anecdote above, both users would have
 been satisfied if you could *only* call empty without parentheses.
That's a good point. The writeln = 3; is also a good point. :) What I'm trying to defend is the ability to call non-property functions without the parens. I find this: array.stable_sort; file.detach; range.popFront; to look less noisy, clearer and just plain sexier than the respective versions with the parens.
To me, at a glance, it looks like a series of no-ops. Like "x; y; z;". Only upon closer inspection of the names does it become apperent that functions are actually being called.
A consequence of this discussion is that the built-in properties .reverse and .sort MUST be renamed. (Removal would be an acceptable form of renaming IMHO).
Jan 31 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Don (nospam nospam.com)'s article
 Nick Sabalausky wrote:
 "Pelle Månsson" <pelle.mansson gmail.com> wrote in message
 news:hjv9sf$1n5o$1 digitalmars.com...
 On 01/29/2010 07:10 PM, Steven Schveighoffer wrote:
 Note in the anecdote above, both users would have
 been satisfied if you could *only* call empty without parentheses.
That's a good point. The writeln = 3; is also a good point. :) What I'm trying to defend is the ability to call non-property functions without the parens. I find this: array.stable_sort; file.detach; range.popFront; to look less noisy, clearer and just plain sexier than the respective versions with the parens.
To me, at a glance, it looks like a series of no-ops. Like "x; y; z;". Only upon closer inspection of the names does it become apperent that functions are actually being called.
A consequence of this discussion is that the built-in properties .reverse and .sort MUST be renamed. (Removal would be an acceptable form of renaming IMHO).
Yea, can anyone even come up with a good Devil's Advocate argument in favor of leaving these in? The best one I can think of is that, since arrays in D are builtin, the basic functionality for them should also be builtin so they feel "first-class". This is a pretty weak argument. The builtins made sense early on, but now they are slow, inflexible and not substantially easier to use than the std.algorithm functions.
Jan 31 2010
parent bearophile <bearophileHUGS lycos.com> writes:
dsimcha:
 Yea, can anyone even come up with a good Devil's Advocate argument in favor of
 leaving these in?  The best one I can think of is that, since arrays in D are
 builtin, the basic functionality for them should also be builtin so they feel
 "first-class".  This is a pretty weak argument.  The builtins made sense early
on,
 but now they are slow, inflexible and not substantially easier to use than the
 std.algorithm functions.
I don't know. The built-in sort is certified broken, very slow, and too much rigid. But I like the idea of a language that has built-in some very common operations, especially if it already has built-in data structures (like dynamic arrays and associative arrays. Associative arrays are a complex data structure). The good thing of the built in sort is that if you have to sort small groups of many different types of data, you don't need to import algorithms and your binary doesn't inflate because of all those different instances of the sort templated function. In the end I think that: - The sort method from the dynamic arrays can be removed; - The reverse method can be kept; - More useful methods can be added to the associative arrays, I have written about this in the past few times. Bye, bearophile
Jan 31 2010
prev sibling parent torhu <no spam.invalid> writes:
On 29.01.2010 05:20, Steven Schveighoffer wrote:
 Andrei Alexandrescu Wrote:

  Michiel Helvensteijn wrote:
  >  Andrei Alexandrescu wrote:
  >
  >>>>  foreach (line; stdin.byLine()) { ... }
  >>>>
  >>>>  vs.
  >>>>
  >>>>  foreach (line; stdin.byLine) { ... }
  >>>>
  >>>>  How do I choose?
  >>>  byLine is a property.  It is fetching a range on stdin.
  >>>
  >>>  -Steve
  >>  Damn. I was sure the answer will be different.
  >
  >  byLine() is a function. It changes the state of stdin. Calling it
  >  consecutively will in general result in different return values. If there
  >  were two guys: stdin.currentLine (property) and stdin.nextLine(), it would
  >  be a different story.
No no no. byLine returns a struct, it does not modify stdin. Operating on the struct modifies stdin, but that is outside the call to the property getter. Look at it this way (although this is not the only way to look at it), could byLine be a field inside stdin? It could. You could store a copy of what byLine returns inside stdin, and people could just access it.
Before more time is wasted in this discussion, I would like to point out that byLine does actually have two arguments. I wrote a post about byLine yesterday, but noone seems to have noticed..
Jan 31 2010