On Wed, 19 Nov 2008 19:44:38 +0300, Andrei Alexandrescu
<[EMAIL PROTECTED]> wrote:
Jarrett Billingsley wrote:
On Wed, Nov 19, 2008 at 12:14 AM, Brian <[EMAIL PROTECTED]>
wrote:
I get this (minor) error using dmd 1.036, I don't know if it's been
discovered or not.
test.d(20): Error: template foo!(int) is not a member of actor.world
test.d(20): Error: function expected before (), not 0 of type int
// And heres the code that causes it
class World {
public void foo(T)() {
}
}
class Actor {
World _world;
public World world() {
return this._world;
}
}
void main() {
auto actor = new Actor;
actor._world = new World;
actor.world().foo!(int)(); // This works fine
actor.world.foo!(int)(); // This causes the error
}
This is just another example of the property sugar being subpar. With
real properties, this would not happen. However, as it is,
"actor.world.foo!(int)()" parses as an attempt to access "foo!(int)()"
from the _method_ designated by "actor.world", _not_ from the return
value of actor.world().
I think (in this particular case) it's only about a compiler bug.
Andrei
But you are well aware of _other_ cases in which you _have to_ put an
extra pair of parens to access some property method/field thus broking an
encapsulation and preventing the class designer to replace properties with
fields and vice versa at a later stage.
It's simply broken! You say that empty pair of parens is equivalent to
none of them and thus it is allowed to omit them, but it's not true at
all. There are lots of examples where "auto foo = bar();" != "auto foo =
bar;" and "auto foo = obj.bar();" != "auto foo = obj.bar;" (delegates,
class/struct instances with overloaded opCall, etc).
- such a duality is confusing (when may you omit the parens and when you
may not?)
- it makes the language more complex (rules are so complex that hardly
anyone fully understands them)
- it leads to code inconsistency (half of the programmers remove an
"extra" pair of parens and other half preserve them)
- it is a source of many compiler bugs (this and lots of related ones)
- it contributes to user code bugs that are hard to find at times ("oops,
I missed a pair of parens. God, I thougth that they were optional").
IIRC, true property syntax was a #2 wish among the community according to
a recent "Top 5 D problems" poll and now that a Tango/Phobos common
runtime is implemented it becomes #1.
I really wish I could understand Walter arguments against proper
properties in D...
