On Mon, 25 Apr 2011 15:46:20 -0400, Steve Schveighoffer
<[email protected]> wrote:
From: Robert Jacques <[email protected]>
To: Steve Schveighoffer <[email protected]>; Discuss the phobos
library for D <[email protected]>
Sent: Monday, April 25, 2011 3:29 PM
Subject: Re: [phobos] Time to get ready for the next release
On Mon, 25 Apr 2011 09:58:47 -0400, Steve Schveighoffer
<[email protected]> wrote:
----- Original Message -----
From: Robert Jacques <[email protected]>
To: Discuss the phobos library for D <[email protected]>
Cc:
Sent: Sunday, April 24, 2011 12:03 PM
Subject: Re: [phobos] Time to get ready for the next release
On Sun, 24 Apr 2011 07:33:30 -0400, Jacob Carlborg <[email protected]>
wrote:
If writeln = "foo"; doesn't compile but printf =
"foo"; does then I would consider it not fixed. The way I would want
@property to behave is disallow bar = "foo"; for functions not marked
with @property. But still allow functions not marked with @property
to be
callable without parentheses.
Also, this and another post have given me an idea: what if
non-@property methods
could be assigned to if and only if a valid 'getter' also existed.
This
would still 'fix' writeln = "foo" but be a less restrictive
than an outright ban.
It was an idea that Andrei brought up (before @property syntax was
introduced), but I don't think it can be properly enforced:
int select(int timeout = 0); // both "getter" and "setter"
-Steve
Hmm... good point. Counter-point, select's functions signature is still
a 'setter' signature. A 'select' / 'select()' method doesn't exist,
it's simply syntactic sugar for select(0). Since a lookup of select by
DMD involves the actual function overloads and not their
sugary-transforms, it should still detect that select has no zero-arg
overload and therefore error on 'select = 5'.
Easily worked around:
int select() { return select(0); }
int select(int timeout) { ... }
This seems silly, but it actually is likely to occur with final
interface methods that want to enforce what the default select does.
That makes sense. Thanks for the example and rational.
But in any case, this is diverging into the obscure. I don't think
rules that try to guess what the author is intending are as good as
annotations which tell the compiler what the author is intending.
Of course not, but there's a reason that most cars are automatics: there
is a non-negligible cost to using a heavy annotation based system. The
question isn't so much as is one 'better' or not, but is it good enough
most of the time?
There are problems with using @property alone. There are problem with
using Methods-as-Fields alone. This would indicate that some compromise is
needed, and therefore every point of the synthesis/trade-off curve is
valuable. (Or alternatively that we need to scrape both and start a fresh)
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
