Community

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/

"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?

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.

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

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

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 :)

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

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