View mode: basic / threaded / horizontal-split · Log in · Help
July 19, 2008
Re: Omittable parens is an evil
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
Re: Omittable parens is an evil
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
Re: Omittable parens is an evil
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
Re: Omittable parens is an evil
"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
Re: Omittable parens is an evil
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
Re: Omittable parens is an evil
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
Re: Omittable parens is an evil
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
Re: Omittable parens is an evil
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
Re: Omittable parens is an evil
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
Re: Omittable parens is an evil
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
1 2 3 4
Top | Discussion index | About this forum | D home