digitalmars.D.bugs - fields and methods
- "Kris" <fu bar.com> Jan 06 2006
- "John C" <johnch_atms hotmail.com> Jan 07 2006
- Chris Sauls <ibisbasenji gmail.com> Jan 07 2006
- Bruno Medeiros <daiphoenixNO SPAMlycos.com> Jan 09 2006
- Bruno Medeiros <daiphoenixNO SPAMlycos.com> Jan 09 2006
- "Walter Bright" <newshound digitalmars.com> Jan 09 2006
- "Kris" <fu bar.com> Jan 10 2006
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
Jan 06 2006
"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.
Jan 07 2006
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
Jan 07 2006
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."
Jan 09 2006
Bruno Medeiros wrote: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."
Jan 09 2006
"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.
Jan 09 2006
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.
Jan 10 2006









Chris Sauls <ibisbasenji gmail.com> 