Possible @property compromise
Steven Schveighoffer
schveiguy at yahoo.com
Thu Jan 31 14:54:21 PST 2013
On Thu, 31 Jan 2013 17:11:28 -0500, Zach the Mystic
<reachBUTMINUSTHISzach at googlymail.com> wrote:
> Thanks for looking at it.
>
> I only read the C# documentation for properties briefly, but I didn't
> find my suggestion to be a duplicate of them. In particular, can C#
> properties do anything more than just get and set? My suggestion allows
> harnessing the full power of D struct semantics. Is this not a far more
> expansive solution than what C# has?
C# has properties like this:
property int foo {
get {return _foo;}
set {_foo = value;}
}
Your proposal looks like this:
foo struct {
int opGet() {return _foo;}
void opSet(int value) {_foo = value;}
}
What I see is that the getter and setter are assigned specific contextual
keywords (opGet vs. get, and opSet vs. set). It seems like a very similar
(albeit more verbose) solution.
What I had originally suggested for properties is this:
property int foo {
int get() {return _foo;} // only one getter allowed
void set(int v) {_foo = v;}
void set(float v) {_foo = (int)v;} // more than one setter allowed
}
I think these are all along the same line of solutions. I don't think
they are bad, but clearly they weren't used 4 years ago, so it may be
difficult to convince Walter to use them now.
> My opGet is just another opXXX definable for all structs, not just
> properties.
I didn't see that, but I also don't really see the point of that. What
value does opGet have unless it's a getter for a property?
> I had said it was necessary to achieve structs as properties, but I
> think I was wrong. It's just the equivalent of:
>
> int __someRandomFunction() { return _propValue; }
> alias __someRandomFunction this;
>
> But it would be syntactically nicer, much like Highlander structs are
> syntactically nicer. Therefore, the only language change absolutely
> required would be making non-static structs nested in structs behave
> like non-static structs nested in functions, which they arguably should
> do anyway. Also under the hood, some important optimizations getting rid
> of pointers for data-less structs.
This is a VERY bad idea. A struct is POD. For example, consider a range
type for a container. You may not NEED to have a pointer to the
container, so that is wasted bytes.
Also note that structs are not meant to have internal pointers. So a
"property" struct with an internal pointer
The strange case for a struct type inside a function kind of makes sense,
because of the ability to access the function's variables, and because you
can't really move the stack frame.
-Steve
More information about the Digitalmars-d
mailing list