Suggestion: properties should be treated as 'virtual members variables'

[Steve Horne]

On Tue, 05 Sep 2006 12:57:05 -0400, Marcio <mqmnews123 at sglebs.com>
wrote:

>	Personally I like the Eiffel approach of not requiring () when calling 
>a method that does not need parameters.

Not just Eiffel. D too. I seem to remember Pascal doing the same,
which might be how the idea of properties arose, though I'm really
guessing now.


I've just realised that I have completely misunderstood the problem
myself. But I haven't formed a new understanding. I'm confused. So,
here is my previous understanding and it's fundamental error - please
can someone explain where I'm going wrong...


The starting point is that, in order to handle the example, two
propery calls are needed...

: void f(inout int x) {
:      x++;
: }

That's an inout function, so...

: void func() {
:      A a = new A;
: 
:      f(a.prop);  //error: ((a).prop)() is not an lvalue
: }

The compiler calls the getter and gets a value for the property, but
that result isn't in a variable (an 'lvalue' is normally a variable -
something you can assign into). Without a variable, you can't do a
pass-by-reference for the inout parameter.

Similar problems happen with assignment operators like '++' and '+='.

Compiler level fix - the compiler creates a temporary. The code is
translated to...

  temp = a.prop ();
  f (temp);
  a.prop (temp);

If D doesn't do that fix, the question is why not?

Well, that's what I'm not sure about.


My first thought was that handling the property seems to be a two
stage process during semantic analysis.

Evaluating 'a.prop' seems ambiguous. It might be intended to give a
delegate, or it might be intended to call a property method. An easy
fix is to always give a delegate, but to allow that delegate to
convert to the type of the property using an implicit call.

But, at that second stage, when the delegate is called, the compiler
is dealing with a delegate - not a member function or property. For a
delegate, the compiler doesn't even know what class it relates to -
let alone if there is a setter to match the getter.

With explicit properties, this wouldn't be necessary - there would be
no need to start with an initial delegate since the compiler knows
from the start that it's intended as a property.


OK - but, in principle, the compiler can still handle this without
needing explicit property declarations. All it needs is a more
sophisticated semantic analysis. Instead of creating a 'delegate'
semantic representation, the compiler should create an
'any-one-of-these-things' semantic representation and then use the
context resolve it.


And this is where I'm confused about all this.

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?

Or is it just a 'not done yet' kind of thing?

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