July 19, 2008
Koroskin Denis wrote:

> writefln((&Test.test).mangleof); // prints PFZv, which is a
> pointer to  function
> 

Whre is the bug?

  writefln( typeof( Test.test).stringof);
  writefln( typeof( Test.test).mangleof);
  writefln( typeof( Test.test()).stringof);
  writefln( typeof( Test.test()).mangleof);

prints

  (void())()
  v
  void
  v

-manfred

-- 
Maybe some knowledge of some types of disagreeing and their relation can turn out to be useful: http://blog.createdebate.com/2008/04/07/writing-strong-arguments/
July 19, 2008
Mike wrote:

> "this does something" (parens) and "this is data" (no parens)

Compare this with this extract of your other posting:
>  opAddAssign(auto value) { _bar += value; }
>                // it's extremely extendable!

Yes it is extremely extentable because one can incorporate calls to some arbitrary functions into the body of `opAddAssign':

   opAddAssign(auto value) {
     _bar += value;
     action();
     procedure();
   }

... bang!!! Your "clear _VISUAL_ distinction" has been lost.

-manfred


-- 
Maybe some knowledge of some types of disagreeing and their relation can turn out to be useful: http://blog.createdebate.com/2008/04/07/writing-strong-arguments/
July 19, 2008
Mike Wrote:

> For me it's mostly that there's a clear _VISUAL_ distinction between "this does something" (parens) and "this is data" (no parens); and in D there's no difference in this one (arbitrary) edge case. It's easy to "eyeball scan" code using parens pairs as visual anchors.
> 

I agree. When coding, at first, I was glad to be able to snip the parens (makes code look cleaner), but then I came to the same conclusion - the illusory cleanness of code strikes back in the form of trouble with telling "something" and "do something" apart.

C# has proper properties. Why mess with the classic?

Tomek
July 19, 2008
"Manfred_Nowak" <svv1999@hotmail.com> wrote in message news:g5tmqq$b99$2@digitalmars.com...
> Mike wrote:
>
>> "this does something" (parens) and "this is data" (no parens)
>
> Compare this with this extract of your other posting:
>>  opAddAssign(auto value) { _bar += value; }
>>                // it's extremely extendable!
>
> Yes it is extremely extentable because one can incorporate calls to some arbitrary functions into the body of `opAddAssign':
>
>   opAddAssign(auto value) {
>     _bar += value;
>     action();
>     procedure();
>   }
>
> ... bang!!! Your "clear _VISUAL_ distinction" has been lost.
>
> -manfred
>

When looking at code that accesses a property or uses an operator that is overloadable, you don't usually need to know if extra processing is going on behind-the-scenes (typically only when optimizing). But when looking at code that involves a function, the distrinction between "invoked"/"not invoked" is almost always (if not always) a very important make-or-break matter.


July 19, 2008
On Sun, 20 Jul 2008 01:26:53 +0400, Manfred_Nowak <svv1999@hotmail.com> wrote:

> Koroskin Denis wrote:
>
>> writefln((&Test.test).mangleof); // prints PFZv, which is a
>> pointer to  function
>>
>
> Whre is the bug?
>
>   writefln( typeof( Test.test).stringof);
>   writefln( typeof( Test.test).mangleof);
>   writefln( typeof( Test.test()).stringof);
>   writefln( typeof( Test.test()).mangleof);
>
> prints
>
>   (void())()
>   v
>   void
>   v
>
> -manfred
>

I expected to get `FZv' or, better, `_D4test4Test4testMFZv' and not `v' nor `(void())()'.
The only way I have found so far is to strip the function body and analyze compiler error message:
Error 42: Symbol Undefined _D4test4Test4testMFZv
July 20, 2008
Nick Sabalausky wrote:
> "Manfred_Nowak" <svv1999@hotmail.com> wrote in message news:g5tmqq$b99$2@digitalmars.com...
>> Mike wrote:
>>
>>> "this does something" (parens) and "this is data" (no parens)
>> Compare this with this extract of your other posting:
>>>  opAddAssign(auto value) { _bar += value; }
>>>                // it's extremely extendable!
>> Yes it is extremely extentable because one can incorporate calls to
>> some arbitrary functions into the body of `opAddAssign':
>>
>>   opAddAssign(auto value) {
>>     _bar += value;
>>     action();
>>     procedure();
>>   }
>>
>> ... bang!!! Your "clear _VISUAL_ distinction" has been lost.
>>
>> -manfred
>>
> 
> When looking at code that accesses a property or uses an operator that is overloadable, you don't usually need to know if extra processing is going on behind-the-scenes (typically only when optimizing). But when looking at code that involves a function, the distrinction between "invoked"/"not invoked" is almost always (if not always) a very important make-or-break matter.

I agree. A property getter should be idempotent (cached values aside). That cannot be assumed about all parameter-less functions.
July 20, 2008
Tomasz Sowiñski:
> When coding, at first, I was glad to be able to snip the parens (makes code look cleaner), but then I came to the same conclusion - the illusory cleanness of code strikes back in the form of trouble with telling "something" and "do something" apart.<

I agree that omittable parens is bad, I always put them.
If parens become compulsive you don't need to use "&somefunc", you just use "somefunc" to denote the pointer/delegate and "somefunc()" to call it.

Bye,
bearophile
July 20, 2008
Nick Sabalausky wrote:

> distrinction between "invoked"/"not invoked"

The need for such a distinction is unclear to me, because it seems to be dependent on the level of abstraction one is able to tolerate.

Example:
`int a; a= 1;' can be imagined as writing the value `1' on some peace
of paper labeled `a'.

Under this abstraction one need not care about the physical quality or location of the paper or the writing utensil---or some agent watching that peace of paper and starting some strange action on detecting the value 1.


I.e., although there might be some actions going on, when one assigns a value to a variable, they are moot.


Please note, that it is the habit of thinking, that makes `f' passive and `f()' active. Digital Mars D introduces indeed a change of paradigm into this habit, by peeling off that hiding cover of abstraction.

It should stay this way. The only shortcoming I see, is that there is no element in the language that expresses the wish to have no actions on using some identifier, which is similar to the wish to have some constant values.

But I doubt that one really wants to code: `T a; a#= 1;' or similar to express that one does not want anything executed, even if T represents a class with overloaded opAssign.

-manfred


-- 
Maybe some knowledge of some types of disagreeing and their relation can turn out to be useful: http://blog.createdebate.com/2008/04/07/writing-strong-arguments/
July 20, 2008
Robert Fraser wrote:

> A property getter should be idempotent

How can one assure this?

-manfred

-- 
Maybe some knowledge of some types of disagreeing and their relation can turn out to be useful: http://blog.createdebate.com/2008/04/07/writing-strong-arguments/
July 20, 2008
bearophile wrote:
> Tomasz Sowiñski:
>> When coding, at first, I was glad to be able to snip the parens (makes code look cleaner), but then I came to the same conclusion - the illusory cleanness of code strikes back in the form of trouble with telling "something" and "do something" apart.<
> 
> I agree that omittable parens is bad, I always put them.
> If parens become compulsive you don't need to use "&somefunc", you just use "somefunc" to denote the pointer/delegate and "somefunc()" to call it.
> 
> Bye,
> bearophile

Seeing as I don't share your opinion on this topic, I humbly submit that this is not a problem with the language but with the coders, specifically, people who have used function pointers in C.

Since I acquired D before I had much need for that atrocious syntax, &function has always made more sense to me.

Because of this, I do not see a problem with foo or foo() - both are clearly not the function address.

 --downs