On Thu, 31 Jan 2013 19:01:02 -0500, Jesse Phillips
<[email protected]> wrote:
On Thursday, 31 January 2013 at 01:26:19 UTC, Steven Schveighoffer wrote:
On Tue, 29 Jan 2013 23:57:14 -0500, Jesse Phillips
<[email protected]> wrote:
Sorry I have to oppose this. It is in no way a compromise as it is
completely different from everything suggested. I'm going to take this
opportunity to highjack your thread.
You are welcome to it! I don't know if there is a thread on this
newsgroup about properties that hasn't been hijacked.
Thank you.
I should explain that my reasoning behind this is:
1. Walter wants to get rid of @property
I can't really speak to what Walter wants, but I think there is more to
it than removing a keyword.
I meant the @property design, including the keyword. Basically whatever
@property was supposed to stand for.
The compromise is: OK, you want to ditch @property? I can live with
that as long as we have some way to designate properties. How about
this?
I don't think that is a compromise as i don't believe it is @property
that is slated for removal, it is designating something a property.
I don't think that's the case. D1 has a designation of what is a property
-- if it has no arguments it is a getter, if it has a single argument it
is a setter.
The extra rules Walter is proposing are a half-baked design that covers
some cases. But the rules are controlling the behavior based on
superficial observations instead of allowing an author to express specific
intents. It sounds like something Congress would come up with...
Can an pro-@property members claim that the current behavior is what
you want? I believe this answer is no.
The answer is no, but only because what we asked for was never
implemented. What was ORIGINALLY designed with @property (enforcement
of parentheses on functions, enforcement against parentheses on
properties) is what we wanted.
Yep, totally thought that was coming. I'd still be ok with it, but I'm
still partial to not having it enforced, would rather see field ->
property a seamless transition.
First, it's not seamless without a keyword or special syntax (remember the
delegate problem). Second, that's not a mutually exclusive choice. If
you enforce property syntax, then it's still seamless (and even more so
since you actually *CAN* implement what is desired).
It seems at least some members for @property feel that currently
functions are being annotated with @property that shouldn't be.
This is unavoidable. It's like saying I feel some functions are
incorrectly named. @property has nothing to do with it. There is no
"right" answer to whether something should be a @property or not, just
like there is no "right" name for a function.
Yes, but I was thinking more on the degree of wrongness that is
currently acceptable. Something to think on for what my proposal would
be. But again, I don't care about the appearance, only behavior.
Then why ever have properties at all? Functions work just fine.
It also seems those for @property aren't fighting optional parens as
much? Can we discuss fixing the issues we have with this. I think a
good change is to require parens if returning a callable (opposite of
Walters suggestion).
Yes, if the choice is between having the previous implementation (D1)
and optional parentheses with a way to designate properties, I'll
choose the latter.
Walter's suggestion isn't (D1) implementation it address some concerns
with the existing behavior, but doesn't give you a way to declare
properties.
I think you are misunderstanding his proposal. Under his proposal, two
completely unrelated and unconnected functions could combine together to
allow a setter that is completely unintended. Instead of specifying
intent, we have to jump through the compiler hoops to avoid accidental
intent. This is not a solution, it's actually worse than D1 style
properties. You'll have code that can call a 'setter' on an object or
struct with no 'getter' and you'll have no idea why.
I think his suggestions need implemented regardless of what we do with
@property. I think Walter just felt this would appease the pro-property.
I certainly hope none of his suggestions are implemented, they will only
confuse the situation.
If I have my above claims mostly correct, then I'd say @property needs
to be put back in the drawing board and re-implemented.
If you want to replace @property, we need a replacement. @property
still serves a purpose, even in it's currently crippled form.
What purpose is that? Isn't it a no-op by default, and barely enforce ()
with -property?
The purpose is to specify intent "I declare this is a property, use it
that way". It's the whole point of having a property syntax. It's just
not enforced by the compiler.
The compiler has numerous bugs on it, that doesn't mean the features
should be ditched, it means we have to correctly implement those
features. array.dup allows implicit casting away from immutable (at least
it did, not sure if that was fixed). Does that mean we should get rid of
dup?
I'd be for removing it from the language and if we decide on what in
needs to enforce and should be part of the language, then its
implementation is completed in a feature branch and remains out of the
language until it meets the needed enforcement and behavior.
Fine, but leave @property in until you have completed the replacement
feature.
I'm not sure if we are going to have a complete replacement, but your
right, we can leave it in until such a choice is finalized, but let us
get rid of -property.
That doesn't hurt anything, that switch is an experimental feature, and
once we have the blessed property syntax, we likely will need that
experimental feature to obey the new syntax.
The real fact of the matter is, if D never had the "hack" properties it
did, I actually wouldn't care. Calling functions instead of setting or
getting properties is not that horrible. But writeln = "hi" is
horrible.
Yep, introducing properties would have been easy, because no one would
have fallen for the joys of optional parens.
I see only minor issue with optional parens. It's the setters that are
the most disruptive.
writeln = "hi" would not compile with Walters suggested changes.
No, but other abuses would.
In general, the idea is to implement fields without having to create
storage for them. It will never perform as well as a field.
I know, but you can't trust when reading code that is what happens. And
having that convention was being argued for, I like Walter's position of
having the compiler make guarantees and not conventions (I'm sure I've
got some exception I'd want but can't think of one).
The compiler cannot make performance guarantees of any kind really. That
is up to convention. Properties do provide a *mechanism* to create a
convention. What the convention is remains the will of the author.
In other words, go back to D1 properties. No thanks.
Again, it wouldn't be D1, and we aren't going back because that is what
we currently have. We need to fix it.
OK, I stand corrected, if it is a choice between D1 properties and
Walter's new rules, I'll choose D1 properties. At least I know what I get
there. But if we have *any* property syntax at all, I'd prefer that.
Even the current design, while not implemented, has the PROMISE of having
a fully functional property syntax. I prefer the promise of something
that is usable to something that is utterly useless, even if it's already
implemented.
-Steve
