View mode: basic / threaded / horizontal-split · Log in · Help
July 20, 2008
Re: Omittable parens is an evil
Hmm. I thought the whole thing since yesterday, and this is what I think  
describes it best:

foo.   // <- subject
foo;   // <- object
foo(); // <- verb

So it's not a technical question at all, but a grammatical (it only  
affects syntax anyway).

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
July 20, 2008
Re: Omittable parens is an evil
"Manfred_Nowak" <svv1999@hotmail.com> wrote in message 
news:g5vgr4$1buh$2@digitalmars.com...
> Robert Fraser wrote:
>
>> A property getter should be idempotent
>
> How can one assure this?

Making it const/invariant?
July 20, 2008
Re: Omittable parens is an evil
Manfred_Nowak a écrit :
> Robert Fraser wrote:
> 
>> A property getter should be idempotent
> 
> How can one assure this?
> 
> -manfred
> 

Maybe marking the getter as const.
July 20, 2008
Re: Omittable parens is an evil
Manfred_Nowak Wrote:

> 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/

You can't, of course. You can mark it 
invariant, but it may not be in the face of
cached values or non-memory stores. It's
just an assumption many people make and
my own rule whether to make something a
function or a property.

It might be an argument for property 
specific syntax' though.
July 20, 2008
Re: Omittable parens is an evil
downs Wrote:

> 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.

I think functions should be called thisWay() and function addresses should be obtained &thisWay.

But then we would have the question what should thisWay symbol mean without parens or ampersand? Maybe it shouldn't mean anything? or use it only to pass functions into other functions as arguments? hm...

Tomek
July 20, 2008
Re: Omittable parens is an evil
Mike Wrote:

> foo.   // <- subject
> foo;   // <- object
> foo(); // <- verb

now that's a good one!
July 20, 2008
Re: Omittable parens is an evil
On Sun, 20 Jul 2008 23:56:26 +0400, Tomasz Sowiñski <tomeksowi@gmail.com>  
wrote:

> downs Wrote:
>
>> 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.
>
> I think functions should be called thisWay() and function addresses  
> should be obtained &thisWay.
>
> But then we would have the question what should thisWay symbol mean  
> without parens or ampersand? Maybe it shouldn't mean anything? or use it  
> only to pass functions into other functions as arguments? hm...
>
> Tomek

I think it should be used to address to the function itself, like  
typeof(func), func.stringof, func.mangleof, etc.

func() <- function result
&func  <- function pointer
func   <- function itself
July 20, 2008
Re: Omittable parens is an evil
Koroskin Denis Wrote:

> I think it should be used to address to the function itself, like  
> typeof(func), func.stringof, func.mangleof, etc.
> 
> func() <- function result
> &func  <- function pointer
> func   <- function itself

Good idea... Now all we have to do is figure out what this stuff has to do with const, to make Walter think about this :)
July 20, 2008
Re: Omittable parens is an evil
"Koroskin Denis" <2korden@gmail.com> wrote in message 
news:op.uelw2ttaenyajd@worker...
> On Sun, 20 Jul 2008 23:56:26 +0400, Tomasz Sowiñski <tomeksowi@gmail.com> 
> wrote:
>
>> downs Wrote:
>>
>>> 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.
>>
>> I think functions should be called thisWay() and function addresses 
>> should be obtained &thisWay.
>>
>> But then we would have the question what should thisWay symbol mean 
>> without parens or ampersand? Maybe it shouldn't mean anything? or use it 
>> only to pass functions into other functions as arguments? hm...
>>
>> Tomek
>
> I think it should be used to address to the function itself, like 
> typeof(func), func.stringof, func.mangleof, etc.
>
> func() <- function result
> &func  <- function pointer
> func   <- function itself

I've always liked in other languages where the "function pointer/reference" 
and "function itself" are considered one and the same. This just seems like 
extra unnecessary complexity.
July 20, 2008
Re: Omittable parens is an evil
Tomasz Sowiñski <tomeksowi@gmail.com> wrote:

> downs Wrote:
>
>> 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.
>
> I think functions should be called thisWay() and function addresses  
> should be obtained &thisWay.
>
> But then we would have the question what should thisWay symbol mean  
> without parens or ampersand? Maybe it shouldn't mean anything? or use it  
> only to pass functions into other functions as arguments? hm...
>
> Tomek

I usually think that a function called without parens should have no
side effects (except, of course, when used as the lhs. Also, debug
code and logging are also allowed to have side effects). So,

	SomeFunc(); // is a valid line
	SomeFunc; // is invalid
	SomeVar = SomeFunc; // is valid (getter)
	SomeOtherFunc = SomeFunc(); // is valid (setter)

Of course, this is only a coding standard I have set for myself, but
I think it makes code easier to read and understand. As we all know,
WTFs/min is the best way to measure code quality.
http://www.osnews.com/images/comics/wtfm.jpg

-- Simen
1 2 3 4
Top | Discussion index | About this forum | D home