July 20, 2008
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
"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
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
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
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
Mike Wrote:

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

now that's a good one!

July 20, 2008
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
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
"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
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