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.
I should explain that my reasoning behind this is:
1. Walter wants to get rid of @property
2. Dispite 4 years of assuming @property will be implemented, the old
D1-style crap is still in place.
3. I've been using Objective C for the last 10 months, which implements a
similar scheme to properties.
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?
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.
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.
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.
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.
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.
Granted I'm not concerned if it doesn't ever come back. I believe it has
a legitimate role in allowing a change from field to function without
harming usage that can not be achieved without an annotation. However it
seems we can't achieve this with the combination of features D employs.
Ah, your subtle bias shines through ;)
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.
I don't agree with the argument that properties provide a convince to
identify low overhead access. While I'm not experienced in this area,
profile code should indicate where performance is poor, it would be bad
to assume "that looks like a field, so it must not be where the
performance is bad."
In general, the idea is to implement fields without having to create
storage for them. It will never perform as well as a field.
---------------------
So let us decide to keep optional (), fix what we can there.
Define what is desired of properties, but for now get rid of what we
currently know as @property. Then with a complete proposal, we can say
it must meet these goals or it won't exist. Since optional () remain,
introducing @property again will not break code and we will only deal
with broken code now (and there would be some just to fix the current
behavior and its disconnect with -property)
In other words, go back to D1 properties. No thanks.
-Steve
