There seems to be some inconsistency in how method 'fields' are applied?

class A
{
        private bool quit;
        void halt() {quit = true;}
        bool isHalted() {return quit;}
}

void main()
{
        auto a = new A;

        a.halt;         // error here
        a.halt();

        a.isHalted;     // error here
        bool done = a.isHalted;
        if (a.isHalted)
           {
           }
}


compiling:

field.d(12): halt is not a field
field.d(15): isHalted is not a field

"Kris" <fu@bar.com> wrote in message news:dpmt02$1ujf$1@digitaldaemon.com...
> There seems to be some inconsistency in how method 'fields' are applied?

I'm not sure there is such a thing in D. Maybe you mean 'properties'?

>
> class A
> {
>        private bool quit;
>        void halt() {quit = true;}
>        bool isHalted() {return quit;}
> }
>
> void main()
> {
>        auto a = new A;
>
>        a.halt;         // error here

A.halt is neither a property nor a field, so must be called with parentheses, as below.

>        a.halt();
>
>        a.isHalted;     // error here

As above.

>        bool done = a.isHalted;

This worked because A.isHalted meets the criterion of being a property.

class A {
    private bool quit;
    bool halt() { return quit = true; }
}

int main() {
    auto a = new A;
    bool halted = a.halt;
    return 0;
}

However, omit 'bool halted = ' and D won't treat 'A.halt' as a property, rather as a method.

>        if (a.isHalted)
>           {
>           }
> }
>
>
> compiling:
>
> field.d(12): halt is not a field
> field.d(15): isHalted is not a field
>
>

Yet another reason to have a special notation for properties.

John C wrote:
> Yet another reason to have a special notation for properties. 

Main reason.  Properties need a special notation, specifically because as D stands, it really doesn't have properties at all...  It has a property-like syntax sugar that applies in select cases.  This is why I personally almost never use D's "properties" at all, although I admittedly do use the specific pattern that D properties are written in.  So /if/ they can be cleaned up to work in all cases, I guess I could be satisfied, but I'd prefer a new notation.

-- Chris Sauls

John C wrote:
> "Kris" <fu@bar.com> wrote in message news:dpmt02$1ujf$1@digitaldaemon.com...
> > ...
> ...

This issue has nothing to do with properties.
It has to with the D feature that the 'value' (or better said, the evaluation result) of a function that has zero parameters is its function call, unlike in C where the value is the memory address.

somefunc  // in C it is &somefunc
somefunc  // in D it is somefunc()

And what we seem to have here is a bug (?) with this feature. Here's a simpler example, without classes involved:

  void func() { writefln("in func()"); }

  int main(char[][] args)
  {
	func;                      // does nothing
	func, "dummy_expression";  // calls func()
  }


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

Bruno Medeiros wrote:
> 
>   void func() { writefln("in func()"); }
> 
>   int main(char[][] args)
>   {
>     func;                      // does nothing
>     func, "dummy_expression";  // calls func()
>   }
> 
>
Agh, musn't forget the return from main.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

"Kris" <fu@bar.com> wrote in message news:dpmt02$1ujf$1@digitaldaemon.com...
> There seems to be some inconsistency in how method 'fields' are applied?

It's a bug, I'll fix it.

Thx;


"Walter Bright" <newshound@digitalmars.com> wrote in message news:dpvnlf$1deb$1@digitaldaemon.com...
>
> "Kris" <fu@bar.com> wrote in message news:dpmt02$1ujf$1@digitaldaemon.com...
>> There seems to be some inconsistency in how method 'fields' are applied?
>
> It's a bug, I'll fix it.
>