"Steve Horne" <stephenwantshornenospam100@aol.com> wrote in message news:7i52g25vn3qkg41uhoako5jmr5135jif0u@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.

Just thought I'd point out another shortcoming of the current approach to properties.
Suppose you have the following code:

class Foo
{
  void delegate() bar;

  void func()
  {
    writefln( "example" );
  }

  this()
  {
    bar = &func;
  }
}

void main()
{
  Foo foo = new Foo();
  foo.bar();
}

This prints "example".  But now the class is rewritten so that the delegate is hidden behind a property:

class Foo
{
  void delegate() m_bar;
  void delegate() bar() { return m_bar; }

  void func()
  {
    writefln( "example" );
  }

  this()
  {
    m_bar = &func;
  }
}

void main()
{
  Foo foo = new Foo();
  foo.bar();
}

Unfortunately this still compiles and runs...  incorrectly.  It prints nothing.  foo.bar() just returns a delegate, but doesn't call it.

IMO, this is quite underpowered compared to what something like C# gives you.  Currently it's just shorthand for function calling, and that hardly helps me.  I don't mind typing a few extra characters to call a function.  What I want is to be able to treat properties as data members in /every/ way on the calling side.

I hope there are plans to change the current state of properties at some point, regardless of backwards compatibility.

Kristian wrote:
> 
> In digitalmars.D.announce there has been discussion about why you cannot  use properties as data members. For example, why the following (simple)  example doesn't work:
> 
> class A {
>     int prop() {return m_val;}
>     int prop(int val) {return m_val = val;}
> 
>     int m_val = 0;
> }
> 
> void f(inout int x) {
>     x++;
> }
> 
> void func() {
>     A a = new A;
> 
>     f(a.prop);  //error: ((a).prop)() is not an lvalue
> }
> 
> 
> I think properties should work just like they were data members:  everywhere you could give a data member you can also give a property. So,  for example, the following should also work:
> 
> a.prob++;
> a.prob -= 10;
> 
> Hence the implementation of 'prob' will be hidden from the user.
> 
> I would very much see properies as a 'virtual member variables'.
> 
> 
> Hmm, would it be simplier to implement properties by using virtual tables  for variables?...
> 
> (What object oriented languages did for functions, D does it for  variables! *grin*)

On Fri, 8 Sep 2006 10:15:45 -0400, "Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote:

>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.

Yeah, I know. I guess I'm just used to C++ creating temporaries whenever it feels like it.

I guess the problem with that is that the temporaries aren't free, and aren't always cheap. So better to think extra hard before adding a compiler feature that people will get dependent on.

It still feels wrong, though, to have properties that can't always do the job of the data fields they are meant to replace. Still much better than not having properties, though.

-- 
Remove 'wants' and 'nospam' from e-mail.