www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Suggestion: properties should be treated as 'virtual members variables'

reply Kristian <kjkilpi gmail.com> writes:
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 =3D val;}

     int m_val =3D 0;
}

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

void func() {
     A a =3D 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 -=3D 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 table=
s  =

for variables?...

(What object oriented languages did for functions, D does it for  =

variables! *grin*)
Sep 05 2006
next sibling parent reply Reiner Pope <reiner.pope REMOVE.THIS.gmail.com> writes:
While we're discussing this, I'm wondering: what is the reason that D 
doesn't use explicit properties like C# does?

Somewhere, the spec says that properties are useful for turning a pure 
data member into a getter/setter pair without breaking code. C# 
properties allow this feature, including the required syntax for 
treating them as lvalues, and I believe this is pretty safe because of 
the explicit nature of declaring properties.

Walter, is there a reason you decided against such a syntax, or are you 
simply not aware of it?

As to the solution for D, I like what Derek proposed:

a.func();

means func is treated as a function, with no special semantics (which 
means it can't be an lval), but

a.func;

means that func is treated as a property. This means a getter is 
required for rval semantics and a setter is required for lval semantics.

However, the problem with this is that it does not obviously scale. For 
instance, how does this approach work with opIndex(Assign) where there 
are multiple parameters? Should the solution to this only work for 
opIndex, or should it apply to arbitrary functions?

I haven't given this too much thought, but my current inclinations is 
that an explicit syntax is the right way to manage this. This suggestion 
here would be very similar to C# properties, but can support extra 
parameters:

1. Add the keyword 'property', 'value', 'get' and 'set'. Alternatively, 
you could use -> and <- instead of get and set if the keywords are 
already used too much.

2. Syntax looks like this:

class C
{
	private int m_val;
	// Looks just like C# but has the property keyword to distuinguish from 
a nested function. This is the simplest type of property.
	property int Val
	{
		get { return m_val; }
		set { m_val = value; }
	}
}

This would get expanded to

class C
{
	private int m_val;
	int __set_Val(int value) { return m_val = value; }
	int __get_Val() { return m_val; }
}

However, the difference from C# is that you can give parameters to 
properties:


class D
{
	private int[] myArray;
	property int myAccessor(int index)
	{
		get { return myArray[index]; }
		set { myArray[index] = value; }
	}
}

Being explicit like this lets you pair up arbitrary functions into 
getters and setters to behave like this. To ensure against unexpected 
behaviour, then you keep Derek's rule:

a.foo; // requires foo is a property or data member
a.foo(); // requires foo is a function

Thanks for following this disjointed post.

Cheers,

ReinerHmm, 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*)
Sep 05 2006
parent reply mike <vertex gmx.at> writes:
Hi!

I hope you don't mind if I throw in some ideas on that.

 2. Syntax looks like this:

 class C
 {
 	private int m_val;
 	// Looks just like C# but has the property keyword to distuinguish fr=

 a nested function. This is the simplest type of property.
 	property int Val
 	{
 		get { return m_val; }
 		set { m_val =3D value; }
 	}
 }

One could get even further and expand the C#-style syntax: (1) Get rid of superflous {} characters when there's only one statement.= ' property int Val ' { ' get return m_val; ' set ' { ' assert(value < 20); ' m_val =3D value; ' } ' } (2) Introduce new "operators". Maybe use operator notation? ' property int Val ' { ' get return m_val; ' set ' { ' assert(value < 20); ' m_val =3D value; ' } ' increase ' { ' assert(value < 19); ' return m_val++; ' } ' decrease ' { ' assert(value > 0); ' return m_val++; ' } ' } (3) Finally - maybe use opXX() notation so there won't be lots of new = keywords and with the () it fits more nicely into the syntax. ' property int Val ' { ' opReturn() return m_val; ' opAssign(int value) ' { ' assert(value < 20); ' m_val =3D value; ' } ' opIncrement() ' { ' assert(value < 19); ' return m_val++; ' } ' opDecrement() ' { ' assert(value > 0); ' return m_val++; ' } ' } I like (3) very much. -Mike -- = Erstellt mit Operas revolution=E4rem E-Mail-Modul: http://www.opera.com/= mail/
Sep 05 2006
next sibling parent Kristian <kjkilpi gmail.com> writes:
On Tue, 05 Sep 2006 17:10:59 +0300, mike <vertex gmx.at> wrote:
 Hi!

 I hope you don't mind if I throw in some ideas on that.

 2. Syntax looks like this:

 class C
 {
 	private int m_val;
 	// Looks just like C# but has the property keyword to distuinguish  =


 from a nested function. This is the simplest type of property.
 	property int Val
 	{
 		get { return m_val; }
 		set { m_val =3D value; }
 	}
 }

One could get even further and expand the C#-style syntax: (1) Get rid of superflous {} characters when there's only one statemen=

 ' property int Val
 ' {
 '      get return m_val;
 '      set
 '      {
 '          assert(value < 20);
 '          m_val =3D value;
 '      }
 ' }

 (2) Introduce new "operators". Maybe use operator notation?

 ' property int Val
 ' {
 '      get return m_val;
 '      set
 '      {
 '          assert(value < 20);
 '          m_val =3D value;
 '      }
 '      increase
 '      {
 '          assert(value < 19);
 '          return m_val++;
 '      }
 '      decrease
 '      {
 '          assert(value > 0);
 '          return m_val++;
 '      }
 ' }

 (3) Finally - maybe use opXX() notation so there won't be lots of new =

 keywords and with the () it fits more nicely into the syntax.

 ' property int Val
 ' {
 '      opReturn() return m_val;
 '      opAssign(int value)
 '      {
 '          assert(value < 20);
 '          m_val =3D value;
 '      }
 '      opIncrement()
 '      {
 '          assert(value < 19);
 '          return m_val++;
 '      }
 '      opDecrement()
 '      {
 '          assert(value > 0);
 '          return m_val++;
 '      }
 ' }

 I like (3) very much.

 -Mike

The syntax of (3) is nice if properties can have multiple operators. (There is very close relation between a property and a class. A property= = has only operators and it's logically treated as a data member of its = type.) But, because you cannot overload operators of basic types, how should th= e = following work: void f(inout int v) { v++; } f(obj.Val); The 'opIncrement' operator (or 'opAdd()') of 'Val' cannot be called insi= de = 'f()'. The answer to this is that the compiler does the following (as wa= s = described in an earlier message): auto x =3D obj.Val; f(x); obj.Val =3D x; This means that everything should be doable with the read and write = operators only. Hence I think that there would not be need for the other= = operators. So (1) looks very nice.
Sep 05 2006
prev sibling parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Tue, 05 Sep 2006 22:21:39 +1000, Reiner Pope
<reiner.pope REMOVE.THIS.gmail.com> wrote:

While we're discussing this, I'm wondering: what is the reason that D 
doesn't use explicit properties like C# does?

Walter, is there a reason you decided against such a syntax, or are you 
simply not aware of it?

If I can throw in a guess, it is sometimes kind of nice that a property can be treated as a method. For instance, if you need a delegate for a getter/setter function to pass to another function, you don't need to write it again - you just use the existing property. That said, I'm not sure if the trade-off works. Explicit properties have been around for a while - not just C# but, IIRC, Delphi, C++Builder, Visual C++ (even without .NET), Python. They work well enough. I've not had the experience with the D method to form a clear opinion yet, but I have my doubts. On Tue, 05 Sep 2006 16:10:59 +0200, mike <vertex gmx.at> wrote:
One could get even further and expand the C#-style syntax:

(1) Get rid of superflous {} characters when there's only one statement.

' property int Val
' {
'      get return m_val;
'      set
'      {
'          assert(value < 20);
'          m_val = value;
'      }
' }

One advantage of the D method is just a little bit more flexibility. With setters, you can decide whether to return the assigned value or not. That means you can decide whether to support the following... var1 = obj.propertyname = var2; Don't know how important that choice is in D yet, but certainly in C++ I don't always return anything from a custom assignment operator. -- Remove 'wants' and 'nospam' from e-mail.
Sep 06 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Kristian" <kjkilpi gmail.com> wrote in message 
news:op.tfelx1zc5xlco7 mist...

 I think properties should work just like they were data members: 
 everywhere you could give a data member you can also give a property.

I totally agree. In my scripting language (or rather, in a previous incarnation of it), I wanted C#-style explicit properties, such as: class Foo { def int mX; property int x { set(int value) { return mX = value; } get { return mX; } } } .. def Foo f = new Foo(); f.x = 4; writefln(f.x); f.x += 6; // == f.x.set(f.x.get() + 6) writefln(f.x); Then I got even more general, and came up with namespaces + operator overloading: class Foo { def int function(int)[] mCallbacks; namespace callbacks { def int function(int)[] opGet() { return mCallbacks.dup; } def void opCatEq(int function(int) func) { mCallbacks ~= func; } def int function(int) opIndex(int index) { return mCallbacks[index]; } def int length() { return mCallbacks.length; } } } ... def Foo f = new Foo(); f.callbacks ~= someFunc; f.callbacks ~= anotherFunc; for(def int i = 0; i < f.callbacks.length(); ++i) writefln("callback ", i, ": ", f.callbacks[i]); def int function(int)[] cb = f.callbacks; The advantage to this is that you can make really complex and abstract "data structures" out of what really amounts to syntactic sugar. And unlike nested structs or classes, these members can be overridden, since the namespace only adds a piece to the name instead of creating an entirely new data structure. And namespaces can live anywhere, and not just in classes... OK, I'm going off on a bit of a tangent here, and it's doubtful Walter would go this far. We can dream, though :) But I think the point everyone is trying to make with wanting explicit property syntax is that if the compiler _knows_ about properties, it can do cool things with them. I mean, Walter echoes this sentiment here: http://www.digitalmars.com/d/builtin.html . Right now, the compiler doesn't know anything about properties; they're nothing more than a hackish way to write a function call.
Sep 05 2006
parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Tue, 5 Sep 2006 09:52:44 -0400, "Jarrett Billingsley"
<kb3ctd2 yahoo.com> wrote:

Then I got even more general, and came up with namespaces + operator 
overloading:

class Foo
{
    def int function(int)[] mCallbacks;

    namespace callbacks
    {
        def int function(int)[] opGet()
        {
            return mCallbacks.dup;
        }

    }
}

I like it. It reminds me of something I did with properties in Python, even though it was a lot of hassle. I wanted reverse iteration. I solved it by having a 'reverse' propery which returned a proxy object. The proxy referred back to the original, but implemented some methods 'backwards'. Request an iterator and you get one, but set up to generate the values in reverse order. I had a class set up to represent 'the set of integers', so that I could use slicing and reversing to specify a range of values for a for loop such as... for i in Integers.reverse [0:10] : The point being that writing a reversed slice (with a half-open range) is just slightly painful - reversing the above slice gives [9:-1:-1] for instance. It was proof of concept rather than real code, but I liked the result. But I didn't really want a proxy. I just wanted an easy notation. Your 'namespace' syntax could have given me the same notation, and avoided the proxy object overhead. Another thought - overloaded constructors by name. There are sometimes different ways to construct an object for different purposes. They can't always be separated by signature, and even if they can, the signature doesn't always express the purpose. Usual solution - only partly construct the object, and use ordinary methods to finish the initialisation. Putting a constructor in one of your namespaces would, it seems, do the trick, allowing... c_Object l_Object = new c_Object.alt_constructor_name (blah); I seem to remember Turbo Pascal allowing any method to be declared as a constructor for similar reasons, though that was a long long time ago and I've never used Delphi. I assume the special-constructor-name systems main benefit is that there's an obvious default constructor, but it would still be nice to have named alternatives at times. -- Remove 'wants' and 'nospam' from e-mail.
Sep 08 2006
prev sibling next sibling parent reply Marcio <mqmnews123 sglebs.com> writes:
Kristian wrote:
 
 In digitalmars.D.announce there has been discussion about why you cannot 
 use properties as data members.

Personally I like the Eiffel approach of not requiring () when calling a method that does not need parameters. This allows the implementer of the class to switch between a plain slot or real code that gets run to compute&return, without impacting clients. No modification is needed at the source code level at client classes. Users just say a.foo and the foo implementer can choose the best implementation approach. No complicated notation to define it "as a property" etc. It is true that you can't assign to it to change it (a.foo := 3), you still need the method call notation (something that properties do for you, that extra syntax sugar). Some people like it better this way, some people prefer being able to assign (conceptually). marcio
Sep 05 2006
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Marcio" <mqmnews123 sglebs.com> wrote in message 
news:edka8t$2e0j$1 digitaldaemon.com...

 Personally I like the Eiffel approach of not requiring () when calling a 
 method that does not need parameters. This allows the implementer of the 
 class to switch between a plain slot or real code that gets run to 
 compute&return, without impacting clients. No modification is needed at 
 the source code level at client classes. Users just say a.foo and the foo 
 implementer can choose the best implementation approach. No complicated 
 notation to define it "as a property" etc.

But this _is_ how D does it right now, i.e. class Foo { int bar() { return 4; } } Foo f = new Foo(); writefln(f.bar); Or even: int foo() { return 5; } writefln(foo); We're not happy with this, because of the expressivity that is lost when using things like op=.
Sep 05 2006
prev sibling parent reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Tue, 05 Sep 2006 12:57:05 -0400, Marcio <mqmnews123 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.
Sep 08 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
Sep 08 2006
parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
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.
Sep 09 2006
prev sibling parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
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*)

Sep 08 2006