"Andrei Alexandrescu" wrote
> Steven Schveighoffer wrote:
>> "Andrei Alexandrescu" wrote
>>>> P.S. If src.next() is too lengthy, why not just adopt ++src?
>>> Because people (in wake of the recently introduced array operations) may legitimately expect that to mean "increment all elements of src".
>>
>> So in one case, you believe people's assumptions aren't important, i.e. an assumption that .next without parens will not change anything on the object, yet in another case you believe people's assumptions are the main argument. This doesn't sound consistent.
>
> Of course it is. One expectation has to do with operational consistency (albeit a tad far-fetched), the other has to do with being used to a mistaken decision in the C language design.

You are assuming that the C language decision to require parentheses for all functions was a design mistake.  I would argue that the design was on purpose and correctly served that purpose.  The purpose was to remove ambiguity when faced with understanding code without all the context.

But that isn't even the questioned practice here.  C designers didn't even come across the question of whether an accessor-property should imply no changes to the object, because they don't have properties.  The real problem is that no matter how you define next(), you can use it in a way which makes it appear like an accessor, not a function which modifies the object.  The source of the problem is D's lack of expressiveness, where I cannot define whether a function cannot be used as a property.

Even with a true property definition syntax, you cannot prevent someone from changing an object while inside an accessor, that should be defined by the constancy of the object in question.  But indicating that it is preferred to use the property-style means to access the next() member function seems to be misleading to some people.

The problem I have with your argument is how you used one case to say 'this is misleading to people, so it's not a valid solution', and in another case say 'it's only misleading because you are used to it, that doesn't matter.' The assumption of which people are important to please is the issue.  I understand you can't please everyone, but you shouldn't use the 'people won't like it' argument without real evidence or proof.

>> Not that I care too much :)  I am also in the camp of 'defined properties should be a language feature,' but I admit to using D-properties quite often.
>>
>> The two things that bug me the most about D property syntax:
>>
>> stuff like this:
>>
>> x;
>>
>> What the hell does this mean?  It looks like it does nothing.  But it could be a function call.  If explicit properties were required, and x was defined as a function, not a property, then x; would be a syntax error.
>
> And what would be the advantage? I routinely use writeln; without feeling it makes for inferior style.

The advantage is not to you, it is to the reader of your code.  writeln; is a complete misuse of property syntax, and IMO should not be allowed. writeln is not a property, and shouldn't be used like a property.  I routinely use Tango's Stdout.newline; which I admit goes against what I am saying, but it's because I know what Stdout.newline does, and that it is a function.  I would gladly change everything to Stdout.newline() if it was required.

The problem is not that you or anyone might forget that writeln is a function and not a property, the problem is when you start using the property syntax to call functions that aren't so standard, someone reading the code will be confused as to what the code is supposed to do.

The advantage is, you are able to define how a symbol behaves, what the rules are for using it.  It makes for clearer code.

-Steve

Steven Schveighoffer wrote:
> "Andrei Alexandrescu" wrote
>> Steven Schveighoffer wrote:
>>> "Andrei Alexandrescu" wrote
>>>>> P.S. If src.next() is too lengthy, why not just adopt ++src?
>>>> Because people (in wake of the recently introduced array operations) may legitimately expect that to mean "increment all elements of src".
>>> So in one case, you believe people's assumptions aren't important, i.e. an assumption that .next without parens will not change anything on the object, yet in another case you believe people's assumptions are the main argument. This doesn't sound consistent.
>> Of course it is. One expectation has to do with operational consistency (albeit a tad far-fetched), the other has to do with being used to a mistaken decision in the C language design.
> 
> You are assuming that the C language decision to require parentheses for all functions was a design mistake.  I would argue that the design was on purpose and correctly served that purpose.  The purpose was to remove ambiguity when faced with understanding code without all the context.

I have stated my assumption and its basis. What is the basis of yours?

> But that isn't even the questioned practice here.  C designers didn't even come across the question of whether an accessor-property should imply no changes to the object, because they don't have properties.  The real problem is that no matter how you define next(), you can use it in a way which makes it appear like an accessor, not a function which modifies the object.  The source of the problem is D's lack of expressiveness, where I cannot define whether a function cannot be used as a property.

I understand your argument, but it hinges on its own definitions and assumptions. You define "accessor" and then complain that something looks like one unexpectedly. Well in some languages a.b does not change anything. In others it does. What gives?

> Even with a true property definition syntax, you cannot prevent someone from changing an object while inside an accessor, that should be defined by the constancy of the object in question.  But indicating that it is preferred to use the property-style means to access the next() member function seems to be misleading to some people.

So that further weakens your argument.

> The problem I have with your argument is how you used one case to say 'this is misleading to people, so it's not a valid solution', and in another case say 'it's only misleading because you are used to it, that doesn't matter.' The assumption of which people are important to please is the issue.  I understand you can't please everyone, but you shouldn't use the 'people won't like it' argument without real evidence or proof.

I agree that ++array may not be easily confused with ++array[]. The situation I am trying to help is improve on a mistake in the C language design that we got so used to, we actually think it's the right thing.

>>> Not that I care too much :)  I am also in the camp of 'defined properties should be a language feature,' but I admit to using D-properties quite often.
>>>
>>> The two things that bug me the most about D property syntax:
>>>
>>> stuff like this:
>>>
>>> x;
>>>
>>> What the hell does this mean?  It looks like it does nothing.  But it could be a function call.  If explicit properties were required, and x was defined as a function, not a property, then x; would be a syntax error.
>> And what would be the advantage? I routinely use writeln; without feeling it makes for inferior style.
> 
> The advantage is not to you, it is to the reader of your code.  writeln; is a complete misuse of property syntax, and IMO should not be allowed. writeln is not a property, and shouldn't be used like a property.

Aside from just saying it, do you have any substantive argument?

> I routinely use Tango's Stdout.newline; which I admit goes against what I am saying, but it's because I know what Stdout.newline does, and that it is a function.  I would gladly change everything to Stdout.newline() if it was required.

To what benefit? You seem to be using it today, and that makes your own style incongruent with your argument, yet surely you'd change the style in an iffy if you thought it has serious drawbacks.

> The problem is not that you or anyone might forget that writeln is a function and not a property, the problem is when you start using the property syntax to call functions that aren't so standard, someone reading the code will be confused as to what the code is supposed to do.
> 
> The advantage is, you are able to define how a symbol behaves, what the rules are for using it.  It makes for clearer code.

I am not sure.


Andrei

Andrei Alexandrescu wrote:
> Steven Schveighoffer wrote:
>> You are assuming that the C language decision to require parentheses for all functions was a design mistake.  I would argue that the design was on purpose and correctly served that purpose.  The purpose was to remove ambiguity when faced with understanding code without all the context.
> 
> I have stated my assumption and its basis. What is the basis of yours?

Yum. I think the problem is that when C was designed, K&R didn't consider
the use of classes with properties using getter and setter methods.
Therefore, it made sense to have the naked function name denote the
function pointer, and make braces following an identifier the mark of a
function call. I initially had some trouble accepting the explicit & in D
to get the function pointer myself.
I wouldn't go so far as to call that property of C a design mistake in
light of the actual intensions of K&R. But I definitely would defend
the choice of a language designer to change that feature in light of
more modern programming paradigms.

regards, frank

In article <gbjihf$2803$1@digitalmars.com>, frank@youknow.what.todo.interNETz says...
> Andrei Alexandrescu wrote:
> > Steven Schveighoffer wrote:
> >> You are assuming that the C language decision to require parentheses for all functions was a design mistake.  I would argue that the design was on purpose and correctly served that purpose.  The purpose was to remove ambiguity when faced with understanding code without all the context.
> > 
> > I have stated my assumption and its basis. What is the basis of yours?
> 
> Yum. I think the problem is that when C was designed, K&R didn't consider
> the use of classes with properties using getter and setter methods.
> Therefore, it made sense to have the naked function name denote the
> function pointer, and make braces following an identifier the mark of a
> function call. I initially had some trouble accepting the explicit & in D
> to get the function pointer myself.
> I wouldn't go so far as to call that property of C a design mistake in
> light of the actual intensions of K&R. But I definitely would defend
> the choice of a language designer to change that feature in light of
> more modern programming paradigms.

Functions in D are first-class values.  It's awkward that a first-class value cannot be accessed by its identifier.

> I think that property function call feature in general adds an unnecessary ambiguity to the language.  I'd prefer functions to be callable only with regular function call syntax, and properties be usable only with member access syntax.  The same stands for 'unified function call' feature: if you want to inject a method into an 'array of chars' class you do so explicitly, and only the member call syntax is allowed on that method.  Otherwise code tends to become ambiguous and unreadable.

Or abstracted and generic.

Bent

Steven Schveighoffer wrote:
> "Andrei Alexandrescu" wrote
>>> P.S. If src.next() is too lengthy, why not just adopt ++src?
>> Because people (in wake of the recently introduced array operations) may legitimately expect that to mean "increment all elements of src".
> 
> So in one case, you believe people's assumptions aren't important, i.e. an assumption that .next without parens will not change anything on the object, yet in another case you believe people's assumptions are the main argument. This doesn't sound consistent.

What if it were src.advance instead? Since it's a verb, it's easier to associate it with an action that might change state rather than simply reading the state of src.

As for ++src, I really dislike using that operator overload for an "advance" function. I'd sooner think that src was a fat reference of some sort and calling ++src would increment its value. That said, when I'm working with C or C++, I prefer indexing to pointer manipulation, and I don't use STL collections when I can avoid it, so it's largely a matter of experience.

> Not that I care too much :)  I am also in the camp of 'defined properties should be a language feature,' but I admit to using D-properties quite often.

Properties are good. For one thing, you can get better error messages, like "No set accessor for  Foo.Bar" rather than "Foo.Bar() does not match the given parameters (int)".

> The two things that bug me the most about D property syntax:
> 
> stuff like this:
> 
> x;
> 
> What the hell does this mean?  It looks like it does nothing.  But it could be a function call.  If explicit properties were required, and x was defined as a function, not a property, then x; would be a syntax error.

For me, I use the no-parentheses version in either of these cases:
1. I'm using the function as a property (auto name = field.name).
2. The function name is a verb (mocks.replay).

This seems reasonably unambiguous in my personal experience, though it helps that I have few locals in most of my methods and use a prefix for private members.

Sergey Gromov wrote:
> In article <gbjihf$2803$1@digitalmars.com>, frank@youknow.what.todo.interNETz says...
>> [...]
>> I wouldn't go so far as to call that property of C a design mistake in
>> light of the actual intensions of K&R. But I definitely would defend
>> the choice of a language designer to change that feature in light of
>> more modern programming paradigms.
> 
> Functions in D are first-class values.  It's awkward that a first-class value cannot be accessed by its identifier.

Awkward my sed! Why should a parameterless call be *the* natural meaning
of function identifier access, as opposed to the reference or content?
I don't go for that kind of absolutism, and you don't make sense to me.

0ffh wrote:
> Sergey Gromov wrote:
>> In article <gbjihf$2803$1@digitalmars.com>, frank@youknow.what.todo.interNETz says...
>>> [...]
>>> I wouldn't go so far as to call that property of C a design mistake in
>>> light of the actual intensions of K&R. But I definitely would defend
>>> the choice of a language designer to change that feature in light of
>>> more modern programming paradigms.
>>
>> Functions in D are first-class values.  It's awkward that a first-class value cannot be accessed by its identifier.
> 
> Awkward my sed! Why should a parameterless call be *the* natural meaning
> of function identifier access, as opposed to the reference or content?
> I don't go for that kind of absolutism, and you don't make sense to me.

It may not be "the" natural thing, but it is confusing.

Someone may hate it, but let me compare with other popular languages:

         Function call         Func. ptr. / Func. obj. / delegate   Note
D        func(), func          &func, func (as a template argument)
C-like   func()                func, &func                          [1]
Python   func()                func
Perl     func, func()          "func" (access by &{"func"}())       [2]
VB 6     func                  AddressOf func                       [2]
VB.NET   func()                AddressOf func                     [2,3]
C#       func()                new DelegateType(func)               [3]
Ruby     func, func()          &:func (??)                        [2,4]
Java     func()                <<No such thing??>>
PHP      func()                func, "func" ($x="f";$x();)
Pascal   func                  func                                 [5]
awk      func()                <<No such thing>>                    [6]
sed      b label               <<No such thing>>                    [6]

So, from this table, we see that (except Pascal), if the language calls a function by f(a,b,c,d), then only f() will be considered a valid function call, and a function pointer / function object / delegate is mostly accessed using f, &f or "f".

If D deviates from the norm, fine, since I'm not a language designer, but from the view of programmers also familiar with, hmm, C, C++, ECMAScript, Python and/or PHP, this decision will very likely introduce obstacles or even bugs in development.

Note:
 1. "C-like" includes C, C++ and ECMAScript (Javascript).
 2. I haven't tried what func will give in VB.NET and C#
 3. In VB 6, Perl and Ruby it is acceptable to write "func 4,5" to mean func(4,5), so it may be unfair to compare with D which "func 4,5" is syntax error.
 4. The &:func syntax for Ruby never worked for me. But I'm using Ruby 1.8.
 5. I haven't tested what func really does in Pascal/Delphi, but from online sources (JFGI) it seems that func will return a function pointer if it is passed to a function pointer type.
 6. Since you mentioned AWKward my SED... ;p

On 2008-09-27 00:01:05 -0400, Christopher Wright <dhasenan@gmail.com> said:

> Steven Schveighoffer wrote:
>> "Andrei Alexandrescu" wrote
>>>> P.S. If src.next() is too lengthy, why not just adopt ++src?
>>> Because people (in wake of the recently introduced array operations) may legitimately expect that to mean "increment all elements of src".
>> 
>> So in one case, you believe people's assumptions aren't important, i.e. an assumption that .next without parens will not change anything on the object, yet in another case you believe people's assumptions are the main argument. This doesn't sound consistent.
> 
> What if it were src.advance instead? Since it's a verb, it's easier to associate it with an action that might change state rather than simply reading the state of src.

Very true.


> For me, I use the no-parentheses version in either of these cases:
> 1. I'm using the function as a property (auto name = field.name).
> 2. The function name is a verb (mocks.replay).
> 
> This seems reasonably unambiguous in my personal experience, though it helps that I have few locals in most of my methods and use a prefix for private members.

Indeed. I think all function names which are not simple getters or setters should have a verb in their name, especially in D where there is no syntax difference between a property and a function.

And I like pretty much the feature of not having to put parenthesis for function calls with no arguments. The only problem I have with it is that it makes working with delegates a little messier, especially when dealing with delegate properties which just *can't* behave as normal variables.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 2008-09-26 13:47:55 -0400, "Steven Schveighoffer" <schveiguy@yahoo.com> said:

> I routinely use Tango's Stdout.newline; which I admit goes against what I am saying, but it's because I know what Stdout.newline does, and that it is a function.

I'd argue that for readability of the code "newline" is a bad function name since it has no verb. It should be something like "startLine" or "printNewline" or... "writeln"! Then there would be much less confusion over what it does.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/