Suggestion: properties should be treated as 'virtual members variables'
Jarrett Billingsley
kb3ctd2 at yahoo.com
Fri Sep 8 07:15:45 PDT 2006
"Steve Horne" <stephenwantshornenospam100 at aol.com> wrote in message
news:7i52g25vn3qkg41uhoako5jmr5135jif0u at 4ax.com...
> D must already be doing some of this. After all, take another look...
>
> : class A {
> : int prop() {return m_val;}
> : int prop(int val) {return m_val = val;}
> :
> : int m_val = 0;
> : }
>
> There is a getter _and_ a setter, so when you write 'a.prop' the
> compiler cannot immediately know which method to use for the delegate.
> The same happens any time you create a delegate from an overloaded
> method, not just for properties. The compiler needs to create a
> generalised 'one-of-these-thingies' semantic object, then resolve it
> from context later.
>
> So why not handle inout parameters?
>
> What am I missing?
I thought about it, and it would require the method that takes the inout
param to have different implementations. All an inout parameter really is
is an implicit address-of. So when you write:
void foo(inout int x)
{
x++;
}
int x = 5;
foo(x);
It becomes:
void foo(int* x)
{
(*x)++;
}
int x = 5;
foo(&x);
When you try to pass a property to it, what happens? Properties are
methods, not variables. They have to be called, they can't just be
dereferenced. The inout-taking function can't know whether it's being
passed a method or a variable, and it has to do different things for both.
It just can't work.
More information about the Digitalmars-d
mailing list