www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Fixing D's Properties

reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Properties are a blemish of the D language.  In the first part of this 
post, I'll explain why and try to show how these properties are /not/ 
good or even better than properties in other languages.  Then I'll 
suggest some possible solutions.  I don't care if the solutions I 
suggest are used, but I will be very thankful if this gets fixed somehow.

The first part of this is really for anyone who believes that D's 
properties are just dandy.  So if you've already been bitten by these, 
feel free to skip down to the solution part of the post.

I suppose I should first give some credit to a couple of the strengths 
of D properties:
- They do not need any keywords.
- They can be used outside of classes - pretty much anywhere functions 
can be used.
When I offer a solution, I'll try to make one that preserves these 
advantages.

The following examples are written for D v1.xxx.
They are not tested on D v2.xxx, but may still work.

Here is a list of some of their shortcomings:

-------------------------------------(1)

First, the very common ambiguity:

Does
foo.bar++;
become
foo.bar( foo.bar + 1 );
or
foo.bar() + 1;
??

This is why we can't write things like this:

ubyte[] array = new ubyte[50];
//...
array.length++;
//...
array.length += 10;
// Note how builtin types use properties heavily.

Which means a large set of our beloved shortcut operators are completely 
broken on properties.

-------------------------------------(2)

Second, while the above is problematic, it creates yet another problem!
Unlike other languages with properties like C#, D does not allow easy 
migration from member fields to properties.
Suppose a programmer have a class like so:

class SomeContainer
{
   int data;
}

Someone else using SomeContainer might write code like so:
auto s = new SomeContainer;
s.data++;

Now the programmer does a slight modification to SomeContainer, one that 
he does not expect to break reverse compatibility:

class SomeContainer
{
   private int m_data;
   int data() { return m_data; }
   void data( int value ) { m_data = value; }
}

Now that someone else has a problem, because their code no longer compiles,
since s.data++; is no longer a valid expression.

The ability to write a lightweight interface using fields, and then at 
will promote it to a heavyweight interface of properties, is extremely 
handy.

-------------------------------------(3)

Third, there is a problem with value types and properties.
Consider the following code:

class Widget
{
   Rectangle rect() { return m_rect; }
   void rect( Rectangle value ) { m_rect = value; }

   private Rectangle m_rect;
}

struct Rectangle
{
   int x, y, w, h;

   // just a basic opCall "constructor", nothing important
   static Rectangle opCall( int x, int y, int w, int h )
   {
     Rectangle result;
     result.x = x; result.y = y;
     result.w = w; result.h = h;
     return result;
   }
}

void main()
{
   Widget w = new Widget();

   // Insert some default rectangle.
   // The private field is assigned to so that you can remove the write 
property
   //   and see that the line with w.rect.x = 10; will still compile, even
   //   without a write property!
   w.m_rect = Rectangle( 0, 0, 80, 20 );

   // now comes the fun part...
   w.rect.x = 10;
   assert( w.rect.x == 10 ); // fails
}

That code seems to be trying to write 10 to w's rect's x field.  But it 
doesn't.
It does this instead:
//----
Rect temp = w.rect;
temp.x = 10;
//----
It never writes the temporary back into the widget's field as expected.

Also, try doing as the comment in the example suggests:  uncomment the 
write property, then compile.
Observe how it still compiles, seemingly allowing you to write to a 
property that doesn't exist!

-------------------------------------(4)

Fourth, delegates get the shaft.
Consider this:

class Widget
{
   private void delegate() m_onClick; // called when a click happens.

   void delegate() onClick() { return m_onClick; }
   void onClick( void delegate() value ) { m_onClick = value; }

   // code that polls input and calls onClick() is absent from this 
example.
}

void main()
{
   void handler()
   {
     // handles onClick()
     printf( "Click happened!" );
     // please forgive the use of printf, I don't know whether you are using
     //   Tango or Phobos.
   }

   Widget w = new Widget();

   // When any click happens, we want handler to do it's thing.
   w.onClick = &handler;

   // Now suppose, for whatever reason, we want to emulate a click from 
within
   //   our program.
   w.onClick(); // This does not result in handler() being called!
}

The program DOES NOT print "Click happened!" as expected.  Instead, 
w.onClick expanded to something like this:
void delegate() temp = w.onClick();
That's all it does.  It does not call 'temp'.  It just leaves it there.
That's because there is yet another ambiguity:

Does
foo.bar();
become
T delegate() temp = foo.bar();
or
T delegate() temp = foo.bar();
temp();

Try replacing w.onClick(); with w.onClick()(); and it should work.
IMO, w.onClick()(); is not an obvious way at all to call that delegate.

-------------------------------------(5)

Fifth, delegates aren't over with yet.  This isn't nearly as bad as the 
other 4, but it should hit eventually.
Properties can be converted into delegates.
This is shown in the following example code:

struct Point
{
   private int m_x = 0, m_y = 0;

   int x() { return m_x; }
   void x( int value ) { m_x = value; }

   int y() { return m_y; }
   void y( int value ) { m_y = value; }
}

void main()
{
   Point p;

   int delegate() readX = &p.x;
   p.x = 2;
   printf( "%d", readX() ); // prints 2
}

The problem is, what if, for whatever reason, the author of similar code 
someday wanted to demote those properties back to fields?
In that case, the user code that relies on the delegate will fail.
If properties were treated EXACTLY like fields, you wouldn't be able to 
take their address and call it like a function.  You could take their 
address, but it would just be an address to a value.

Realizing that this behavior of properties can be beneficial, it makes 
sense to show that similar code can be written without properties and 
without much added difficulty.  If we wanted to make a readX function 
like in the above code without properties, we could write something like 
this:

struct Point
{
   int x,y;
}

void main()
{
   Point p;
   int getX() { return p.x; }

   int delegate() readX = &getX;
   p.x = 2;
   printf( "%d", readX() ); // prints 2
}

========================================
           How to fix it
========================================

The most direct solution seems to be explicit properties.  This does not 
mean that the current implicit properties need to be removed.  The two 
can exist together, and the disagreement that may follow is whether the 
implicit ones should be deprecated or not.  I'm not going to worry about 
whether to deprecate implicit properties or not right now.

Here is a table that compares some possible semantics of explicit 
properties against the current implicit properties:

<TT>
+----------------+----------+----------+
|   properties   | explicit | implicit |
+----------------+----------+----------+
| write as field |   yes    |   yes    |
+----------------+----------+----------+
| read as field  |   yes    |   yes    |
+----------------+----------+----------+
|     lvalue*    |   yes    |    no    |
+----------------+----------+----------+
|  overridable** |   yes    |   yes    |
+----------------+----------+----------+
|callable as func|    no    |   yes    |
+----------------+----------+----------+
|use as delegate |    no    |   yes    |
+----------------+----------+----------+
| freestanding***|   yes    |   yes    |
+----------------+----------+----------+
</TT>

*lvalue:  If foo is an lvalue, than foo = 5; should set foo's value to 
5, instead of evaluating to 5; and doing nothing.  Implicit write 
properties fake this to some extent, but do not hold in the general 
case.  Example (3) above and the foo++; and foo+=10; issues are examples 
where lvalueness is needed.
**overridable:  This refers to whether or not the property can be 
overridden when found inside a class.
***freestanding:  The property can be placed anywhere in a file, not 
just inside of classes.  They can also be static and have attributes 
like a function would have.

Another possible change might be to forbid return types for explicit 
write properties (they must return void).  Then, there should be 
well-defined behavior in the D spec for code like this:
foo = bar.x = someValue; // x is an explicit property in bar
This could become
bar.x = someValue;
foo = someValue;
or it could be
bar.x = someValue;
foo = bar.x;
or perhaps something else.
The first case is probably the easiest to understand for people reading 
code.  In the second case foo's final value depends entirely on what 
bar.x does.


Now the only issue is, what should the syntax be for the aforementioned 
explicit properties.
Perhaps something like this:

int foo|() { return bar; }
T foo|( int baz ) { bar = baz; }

Which reuses the '|' character.  Thus these functions named foo are 
explicit properties.  Other characters like '.' or '^' could be used as 
well.  This type of syntax disambiguated templates, it should be able to 
do the same for properties.

Another option would be to reuse a keyword, perhaps inout.

inout
{
   int foo() { return bar; }
   T foo( int baz ) { bar = baz; }
}

which would be equivalent to

inout int foo() { return bar; }
inout T foo( int baz ) { bar = baz; }

Thus 'inout' would be an attribute that enforces explicit propertyness 
on a function or method.
I suppose 'in' could be used for write properties and 'out' for read 
props, but then the curly braced attribute-has-scope syntax would not 
work so well.
At the cost of a keyword, some intuitiveness could be gained.  If said 
single keyword can be added, then perhaps add the keyword 'property' 
with syntax similar to the inout example.

This post is a bit lengthy.  So assuming you've read even part of it, 
thank you for your time.
- Chad
Aug 17 2007
next sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Chad J wrote:
 Properties are a blemish of the D language.  

[snip]
     printf( "Click happened!" );
     // please forgive the use of printf, I don't know whether you are using
     //   Tango or Phobos.

(Seems D is regressing. There used to be a standard library.)
 ========================================
           How to fix it
 ========================================
 
 The most direct solution seems to be explicit properties.

[snip]
 This post is a bit lengthy.  So assuming you've read even part of it, 
 thank you for your time.

I agree with all issues listed with properties. Properties can't be callable both with and without () in order support delegate properties transparently, which means there has to be way to mark them as non-functions. But I am not fully sure I understand your solution to these problems: a.prop++; What should this evaluate to assuming a.prop is an explicit property? What if a.prop returns a reference type (class) with an opPostInc? Likewise: a.prop.y = 7; What should this evaluate to? Any difference if a.prop evaluates to a reference type or a value type? -- Oskar
Aug 17 2007
parent Sean Kelly <sean f4.ca> writes:
Oskar Linde wrote:
 Chad J wrote:
 
 But I am not fully sure I understand your solution to these problems:
 
 a.prop++;
 
 What should this evaluate to assuming a.prop is an explicit property?

Ideally, there should be a way to have both value and reference-based 'get' properties. Sean
Aug 17 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Chad J wrote:
 
 This post is a bit lengthy.  So assuming you've read even part of it, 
 thank you for your time.

All good points. I'd like properties in D to address them all somehow. The 'ref' keyword in 2.0 solves some of the issues, but not others. If doing so requires a special syntax then I'm all for it. Sean
Aug 17 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:
 Chad J wrote:
 This post is a bit lengthy.  So assuming you've read even part of it, 
 thank you for your time.

All good points. I'd like properties in D to address them all somehow. The 'ref' keyword in 2.0 solves some of the issues, but not others. If doing so requires a special syntax then I'm all for it. Sean

What issues does ref fix? You can't return a ref even in 2.0, AFAIK. --bb
Aug 17 2007
parent reply Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:
 Sean Kelly wrote:
 Chad J wrote:
 This post is a bit lengthy.  So assuming you've read even part of it, 
 thank you for your time.

All good points. I'd like properties in D to address them all somehow. The 'ref' keyword in 2.0 solves some of the issues, but not others. If doing so requires a special syntax then I'm all for it.

What issues does ref fix? You can't return a ref even in 2.0, AFAIK.

Oh. I assume this is a planned feature then? Otherwise I see little reason to change "inout" to "ref." Sean
Aug 17 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:
 Bill Baxter wrote:
 Sean Kelly wrote:
 Chad J wrote:
 This post is a bit lengthy.  So assuming you've read even part of 
 it, thank you for your time.

All good points. I'd like properties in D to address them all somehow. The 'ref' keyword in 2.0 solves some of the issues, but not others. If doing so requires a special syntax then I'm all for it.

What issues does ref fix? You can't return a ref even in 2.0, AFAIK.

Oh. I assume this is a planned feature then?

I hope so. That would be great.
 Otherwise I see little 
 reason to change "inout" to "ref."

I thought the reason was more to do with const. Given a const object passed by reference, calling it 'inout' doesn't make much sense. --bb
Aug 17 2007
parent reply Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:
 Sean Kelly wrote:
 
 Otherwise I see little reason to change "inout" to "ref."

I thought the reason was more to do with const. Given a const object passed by reference, calling it 'inout' doesn't make much sense.

This is the explanation I remember as well. But I'm not sure it justifies the addition of a general-purpose sounding keyword simply for parameter passing. "inout" may have been a bit confusing in light of const reference passing, but is consistency with "in" and "out" made it arguably worth retaining. Sean
Aug 17 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:
 Bill Baxter wrote:
 Sean Kelly wrote:

 Otherwise I see little reason to change "inout" to "ref."

I thought the reason was more to do with const. Given a const object passed by reference, calling it 'inout' doesn't make much sense.

This is the explanation I remember as well. But I'm not sure it justifies the addition of a general-purpose sounding keyword simply for parameter passing. "inout" may have been a bit confusing in light of const reference passing, but is consistency with "in" and "out" made it arguably worth retaining.

It's all the more perplexing given that the current D 2.x compiler segfaults on functions declared with const ref parameters. If const refs were the reason for changing 'inout' to 'ref' it is odd that they don't work straight out of the gate. --bb
Aug 17 2007
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
[snip]

I emphatically agree that *something* needs to be done to address the
shortcomings of properties in D.  I mean, what's the point of having
increment/decrement and the op= operators if you cannot use them in a
large number of places?

I do have to say that I'm not a big fan of the symbol-based syntax.
Also, the inout system seems a bit... off.  The problem I have with it
is that *both* the getter and setter are marked inout, which doesn't
make a lot of sense.

Another possibility is to use contract-style notation:

int foo
{
    in(int baz) { bar = baz; }
    out() { return bar; }
}

Or even just dropping "inout" and using "in" and "out" explicitly:

in void foo(int baz) { bar = baz; }
out int foo() { return bar; }

On another note, I think you should expand on exactly how different
kinds of statements should be rewritten.  For instance, you haven't
clarified what happens here:

w.rect.x = 10;

	-- Daniel
Aug 17 2007
parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Daniel Keep wrote:
 [snip]
 
 I emphatically agree that *something* needs to be done to address the
 shortcomings of properties in D.  I mean, what's the point of having
 increment/decrement and the op= operators if you cannot use them in a
 large number of places?
 
 I do have to say that I'm not a big fan of the symbol-based syntax.
 Also, the inout system seems a bit... off.  The problem I have with it
 is that *both* the getter and setter are marked inout, which doesn't
 make a lot of sense.
 
 Another possibility is to use contract-style notation:
 
 int foo
 {
     in(int baz) { bar = baz; }
     out() { return bar; }
 }
 
 Or even just dropping "inout" and using "in" and "out" explicitly:
 
 in void foo(int baz) { bar = baz; }
 out int foo() { return bar; }
 

Looks like it will work, and is fine by me.
 On another note, I think you should expand on exactly how different
 kinds of statements should be rewritten.  For instance, you haven't
 clarified what happens here:
 
 w.rect.x = 10;
 
 	-- Daniel

Aug 17 2007
prev sibling next sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Alright I forgot to mention what something like "a.prop.x = foo;" would 
expand to.

It would work like this:

a.prop.x = foo;

expands to

auto temp = a.prop;
temp.x = foo;
a.prop = temp;

Whether temp is a reference or value type need not matter, it should 
work exactly as it would if there was a variable there instead of a 
property.
I suppose Sean's suggestion of allowing programmers to trap reference 
and value uses of properties would work, but I am skeptical that it 
might break the close compatibility between plain variables (fields) and 
properties.  It should be feasible as long as there is a way to make a 
property equivalent to a field wrt calling syntax/semantics.

Longer chains should be broken down as such:

a.prop1.prop2.field.prop3.x = foo;

->

auto temp1 = a.prop1;
auto temp2 = temp1.prop2;
auto temp3 = temp2.field.prop3;
temp3.x = foo;
temp2.field.prop3 = temp3;
temp1.prop2 = temp2;
a.prop1 = temp1;

Hope that helps.
Aug 17 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Chad J wrote:
 Alright I forgot to mention what something like "a.prop.x = foo;" would 
 expand to.
 
 It would work like this:
 
 a.prop.x = foo;
 
 expands to
 
 auto temp = a.prop;
 temp.x = foo;
 a.prop = temp;
 
 Whether temp is a reference or value type need not matter, it should 
 work exactly as it would if there was a variable there instead of a 
 property.
 I suppose Sean's suggestion of allowing programmers to trap reference 
 and value uses of properties would work, but I am skeptical that it 
 might break the close compatibility between plain variables (fields) and 
 properties.  It should be feasible as long as there is a way to make a 
 property equivalent to a field wrt calling syntax/semantics.
 
 Longer chains should be broken down as such:
 
 a.prop1.prop2.field.prop3.x = foo;
 
 ->
 
 auto temp1 = a.prop1;
 auto temp2 = temp1.prop2;
 auto temp3 = temp2.field.prop3;
 temp3.x = foo;
 temp2.field.prop3 = temp3;
 temp1.prop2 = temp2;
 a.prop1 = temp1;
 
 Hope that helps.

That makes some sense. Although just avoiding the copying by allowing either references or a way to create a light proxy that overloads opDot would be more useful. Then you could return a proxy from 'a' that contains just a pointer to prop2. Either way, D sorely needs a way to overload opDot (akin to C++'s operator->). Not having it eliminates a huge class of useful ways to create value wrappers. There's some seriously cool potential for a CTFE template opDot that takes a string giving the member name. --bb
Aug 17 2007
prev sibling next sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Chad J wrote:
 Properties are a blemish of the D language.  In the first part of this
 post, I'll explain why and try to show how these properties are /not/
 good or even better than properties in other languages.  Then I'll
 suggest some possible solutions.  I don't care if the solutions I
 suggest are used, but I will be very thankful if this gets fixed somehow.
 

Great that you took the time to go through it properly. I agree that all the issues you mentioned need to be fixed somehow. C# uses the "property" keyword IIRC, and even though adding new keywords is a big no-no I find this worth considering. Who uses "property" as an identifier name anyway? -- Remove ".doesnotlike.spam" from the mail address.
Aug 17 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Deewiant wrote:
 Chad J wrote:
 Properties are a blemish of the D language.  In the first part of this
 post, I'll explain why and try to show how these properties are /not/
 good or even better than properties in other languages.  Then I'll
 suggest some possible solutions.  I don't care if the solutions I
 suggest are used, but I will be very thankful if this gets fixed somehow.

Great that you took the time to go through it properly. I agree that all the issues you mentioned need to be fixed somehow.

Ditto.
 C# uses the "property" keyword IIRC, and even though adding new keywords is a
 big no-no I find this worth considering. Who uses "property" as an identifier
 name anyway?

Well, 'property' may be in use by people writing property-editor widgets like in IDEs. But still, I'd go for a new 'property' keyword. Will probably clash with far fewer existing uses that 'ref' did. --bb
Aug 17 2007
prev sibling parent reply BCS <ao pathlink.com> writes:
Reply to Chad,

 -------------------------------------(1)
 
 First, the very common ambiguity:
 
 Does
 foo.bar++;
 become
 foo.bar( foo.bar + 1 );
 or
 foo.bar() + 1;
 ??
 This is why we can't write things like this:
 
 ubyte[] array = new ubyte[50];
 //...
 array.length++;
 //...
 array.length += 10;
 // Note how builtin types use properties heavily.
 Which means a large set of our beloved shortcut operators are
 completely broken on properties.
 

This is not an syntax issue with how proposes are defined, but the semantics of there use. It can be fixed with minor changes.
 -------------------------------------(2)

[...] this is the same as #1 (or am i missing somthing)
 -------------------------------------(3)
 
 Third, there is a problem with value types and properties. Consider
 the following code:
 

short version: struct S {int i; void I(int j){i=j;} } struct P {S s void GetS() { return s;} } P p; p.GetS.I = 5; // assignes 5 to temp, not member of p This is a reference semantics issue. The same isses happens to general functions.
 -------------------------------------(4)
 
 Fourth, delegates get the shaft.

Short version: void delegate() getDG(); getDG(); // calls getDG giving a delgate getDG(); // calls getDG, does not call returned delegate good point.
 
 -------------------------------------(5)
 
 Fifth, delegates aren't over with yet.  This isn't nearly as bad as
 the
 other 4, but it should hit eventually.
 Properties can be converted into delegates.

 The problem is, what if, for whatever reason, the author of similar
 code
 someday wanted to demote those properties back to fields?
 In that case, the user code that relies on the delegate will fail.

 Realizing that this behavior of properties can be beneficial, it makes
 sense to show that similar code can be written without properties and
 without much added difficulty.

 struct Point
 {
 int x,y;
 }
 void main()
 {
 Point p;
 int getX() { return p.x; }
 int delegate() readX = &getX;
 p.x = 2;
 printf( "%d", readX() ); // prints 2
 }

ouch! that sounds worse than the problem you point out.
 ========================================
 How to fix it
 ========================================

 *lvalue:  If foo is an lvalue, than foo = 5; should set foo's value to
 5, instead of evaluating to 5; and doing nothing.  Implicit write
 properties fake this to some extent, but do not hold in the general
 case.  Example (3) above and the foo++; and foo+=10; issues are
 examples
 where lvalueness is needed.

I would disagree. I would clam that the issue is that implicit properties can be used a lvalues or rvalues, but not both. [......] The basis of your thoughts seem to come from the idea that hiding the fact that properties are functions would be a good thing. I would assert that this is highly debatable. I will concede that the current semantics of properties being not quite interchangeable with fields is sub optimal. However fixing this by creating a new construct that, in the end, is identical to a function but with a number of things forbidden seems somehow wrong. As I see it the issues you bring up amount to: 1> no L/R-value usage (++, +=, etc, use as an inout or out arg) 2> they can lead to hard to find reference semantics issues 3> syntax problems with properties retuning delegates 4> not interchangeable with fields #1 can be fixed without explicit properties #2 is not at all a problem in my book #3 This is a tiny corner case #4 this is a good point, however, as stated above, I don't like the proposed solution. Also, the proposed solution doesn't fix the issue because taking the address of a field is allowed, even with explicit properties, this wouldn't work IMHO there are a few minor issues with proposes that could uses a little work. However I don't see much to be gained by you proposal for explicit properties.
 This post is a bit lengthy.  So assuming you've read even part of it,
 thank you for your time.
 - Chad

It's good to see people thinking about this stuff. I may not see your ideas to be the "right" way but, then again, I want different things out of D than many people do.
Aug 17 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
BCS wrote:
 Reply to Chad,

 The basis of your thoughts seem to come from the idea that hiding the 
 fact that properties are functions would be a good thing. I would assert 
 that this is highly debatable.

Ah yes. Although I generally agree with Chad, you did remind me of something. In my Luigi GUI library I use properties for lots of widget settings (things like a button's label, etc), and also rely on being able to call those as delegates for signal-slot connections to set the properties. That's handy, but it only works for members/properties that are written as functions. What I should probably do is to auto-generate a delegate wrapper for pure data members if you try to use one as a slot for a delegate(T setval) type of signal. The other issue it runs into is the overload ambiguity of void foo(int) {} int foo() {} when you take the function reference. One way to resolve the desire to use properties, not pretend they're functions, and still allow usage as a function when possible, would be to allow giving the functions names different from the property name. So then you could do something like: void set_foo(int) {...} int get_foo() {...} property foo(get_foo,set_foo); Or property foo { void set_foo(int) {...} int get_foo() {...} } Of course now you can already make aliases if you just want unambiguous function names to take the address of. (Doesn't prevent using foo() as a function though) void set_foo(int) {...} int get_foo() {...} alias set_foo foo; alias get_foo foo; // not 100% sure this works... --bb
Aug 17 2007
prev sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
BCS wrote:
 Reply to Chad,
 
 -------------------------------------(1)

 First, the very common ambiguity:

 Does
 foo.bar++;
 become
 foo.bar( foo.bar + 1 );
 or
 foo.bar() + 1;
 ??
 This is why we can't write things like this:

 ubyte[] array = new ubyte[50];
 //...
 array.length++;
 //...
 array.length += 10;
 // Note how builtin types use properties heavily.
 Which means a large set of our beloved shortcut operators are
 completely broken on properties.

This is not an syntax issue with how proposes are defined, but the semantics of there use. It can be fixed with minor changes.

What minor changes? If you're going to suggest giving implicit properties lvalueness, then this would break any code that relies on the quirks of current implicit properties. I was hoping to preserve reverse compatibility with my solution, especially since Walter seems conservative about doing anything that breaks existing code.
 
 -------------------------------------(2)

[...] this is the same as #1 (or am i missing somthing)

Promotion != lvalueness The idea here is that #2 is a natural consequence of #1, thus you see them as the same. #2 though, has a different consequence for the programmer. #1 is merely very annoying, while #2 causes nasty code extensibility issues.
 -------------------------------------(3)

 Third, there is a problem with value types and properties. Consider
 the following code:

short version: struct S {int i; void I(int j){i=j;} } struct P {S s void GetS() { return s;} } P p; p.GetS.I = 5; // assignes 5 to temp, not member of p This is a reference semantics issue. The same isses happens to general functions.

Exactly. I don't want function semantics with my properties. I already have function semantics with my functions.
 -------------------------------------(4)

 Fourth, delegates get the shaft.

Short version: void delegate() getDG(); getDG(); // calls getDG giving a delgate getDG(); // calls getDG, does not call returned delegate good point.
 -------------------------------------(5)

 Fifth, delegates aren't over with yet.  This isn't nearly as bad as
 the
 other 4, but it should hit eventually.
 Properties can be converted into delegates.

 The problem is, what if, for whatever reason, the author of similar
 code
 someday wanted to demote those properties back to fields?
 In that case, the user code that relies on the delegate will fail.

 Realizing that this behavior of properties can be beneficial, it makes
 sense to show that similar code can be written without properties and
 without much added difficulty.

 struct Point
 {
 int x,y;
 }
 void main()
 {
 Point p;
 int getX() { return p.x; }
 int delegate() readX = &getX;
 p.x = 2;
 printf( "%d", readX() ); // prints 2
 }

ouch! that sounds worse than the problem you point out.

I disagree, but in light of what you value, it becomes an aesthetics vs functionality issue.
 ========================================
 How to fix it
 ========================================

 *lvalue:  If foo is an lvalue, than foo = 5; should set foo's value to
 5, instead of evaluating to 5; and doing nothing.  Implicit write
 properties fake this to some extent, but do not hold in the general
 case.  Example (3) above and the foo++; and foo+=10; issues are
 examples
 where lvalueness is needed.

I would disagree. I would clam that the issue is that implicit properties can be used a lvalues or rvalues, but not both.

Still doesn't handle promotion/demotion between fields and properties. Also, if you have a way to make the lvalue&rvalue semantics work, let me hear it.
 
 
 [......]
 
 The basis of your thoughts seem to come from the idea that hiding the 
 fact that properties are functions would be a good thing. I would assert 
 that this is highly debatable. I will concede that the current semantics 
 of properties being not quite interchangeable with fields is sub 
 optimal. However fixing this by creating a new construct that, in the 
 end, is identical to a function but with a number of things forbidden 
 seems somehow wrong.
 

Actually, I am suggesting that properties not be functions at all. They will of course share the notion of a body of executable code, but for all intents and purposes they are a way of accessing data while introducing side effects.
 As I see it the issues you bring up amount to:
 
 1> no L/R-value usage (++, +=, etc, use as an inout or out arg)
 2> they can lead to hard to find reference semantics issues
 3> syntax problems with properties retuning delegates
 4> not interchangeable with fields
 
 #1 can be fixed without explicit properties

 #2 is not at all a problem in my book

tell me it isn't a problem!
 #3 This is a tiny corner case

with the related stuff.
 #4 this is a good point, however, as stated above, I don't like the 
 proposed solution. Also, the proposed solution doesn't fix the issue 
 because taking the address of a field is allowed, even with explicit 
 properties, this wouldn't work
 

If the proposed solution is not good enough, please give a better one. Suggestions are welcome and encouraged. As for the address of a field... perhaps if taking the address of a field returned a delegate... nah. This is somewhat of a corner case, but you've got me there, for now. I'd love to see someone come up with a slick solution to this. I should also note that C# didn't seem to have this problem with its explicit properties. That is probably because in C#, using pointers was considered "unsafe" and done very infrequently. It makes me want to bust out C# again and see what happens when one tries to take the address of a property, and I probably will at some point. Even if the addressing thing can't be fixed, I'd at least like to see the rest of the stuff get fixed.
 
 IMHO there are a few minor issues with proposes that could uses a little 
 work. However I don't see much to be gained by you proposal for explicit 
 properties.
 
 This post is a bit lengthy.  So assuming you've read even part of it,
 thank you for your time.
 - Chad

It's good to see people thinking about this stuff. I may not see your ideas to be the "right" way but, then again, I want different things out of D than many people do.

Aug 18 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Chad,

 BCS wrote:
 
 Reply to Chad,
 
 -------------------------------------(1)
 
 First, the very common ambiguity:
 
 Does
 foo.bar++;
 become
 foo.bar( foo.bar + 1 );
 or
 foo.bar() + 1;
 ??



 This is not a syntax  issue with how properties are defined, but the
 semantics of there use.
 It can be fixed with minor changes.

What minor changes? If you're going to suggest giving implicit properties lvalueness, then this would break any code that relies on the quirks of current implicit properties. I was hoping to preserve reverse compatibility with my solution, especially since Walter seems conservative about doing anything that breaks existing code.

How? Letting implicit properties be simultaneously L and R values (they can now be either, just not both at the same time) won't break anything that I know of. Anything that is legal now, still would be, and any cases where the behavior would be different, were illegal to begin with.
 -------------------------------------(2)
 

this is the same as #1 (or am i missing somthing)

The idea here is that #2 is a natural consequence of #1, thus you see them as the same. #2 though, has a different consequence for the programmer. #1 is merely very annoying, while #2 causes nasty code extensibility issues.

If you see them as disticntly different points, then we must be looking at things at different levels. I see both 1 and 2 as saying: "properties can be used with ++, += etc and members can". OK I'll grant that #1 doesn't cover a few cases that #2 does, but that just makes #1 a special case of #2.
 -------------------------------------(3)
 
 Third, there is a problem with value types and properties. Consider
 the following code:
 

struct S {int i; void I(int j){i=j;} } struct P {S s void GetS() { return s;} } P p; p.GetS.I = 5; // assignes 5 to temp, not member of p This is a reference semantics issue. The same isses happens to general functions.

already have function semantics with my functions.

I see your point and I strongly disagree. Under the covers, it IS a function and I /don't/ want that hidden.
 -------------------------------------(5)
 
 Fifth, delegates aren't over with yet.

 the user code that relies on the delegate will fail.

ouch! that sounds worse than the problem you point out.

vs functionality issue.

Unless you can trust the compiler to inline delegate literals (and the potentially virtual function call underneath), it is a performance issue.
 ========================================
 How to fix it
 ========================================

 *lvalue:  If foo is an lvalue, than foo = 5; should set foo's value
 to
 5, instead of evaluating to 5; and doing nothing.  Implicit write
 properties fake this to some extent, but do not hold in the general
 case.  Example (3) above and the foo++; and foo+=10; issues are
 examples
 where lvalueness is needed.

I would disagree. I would clam that the issue is that implicit properties can be used a lvalues or rvalues, but not both.


My point was not intended to. It is a minor issue claming that the mechanics of one of your (valid) issues with implicit properties is incorrectly stated.
 Also, if you have a way to make the lvalue&rvalue semantics work, let
 me hear it.
 

I think that you actually described somewhere the solution I wold use. Use the R-value property (getter) to get the value, do the operation, then use the L-value property (setter) to push it back in. struct S { ... int i(); void i(int); } S s; s.i++; // becomes { auto __tmp = s.i; __tmp++; s.i = __tmp; } If only one or the other property exits then it is assumed the author wants to disallow this type of operation.
 [......]
 
 The basis of your thoughts seem to come from the idea that hiding the
 fact that properties are functions would be a good thing. I would
 assert that this is highly debatable. I will concede that the current
 semantics of properties being not quite interchangeable with fields
 is sub optimal. However fixing this by creating a new construct that,
 in the end, is identical to a function but with a number of things
 forbidden seems somehow wrong.
 

They will of course share the notion of a body of executable code, but for all intents and purposes they are a way of accessing data while introducing side effects.

Will they be accessed by doing a call/return sequence at the machine code level? If so, I would assert they are functions for all purposes I'm interested in. If it would be implemented by some other means, then I have have missed some major point of your post. D is a low level language in many respects, as such, if it looks like a function when it comes out of the compiler, I want to be able to treat it as a function when it goes in.
 As I see it the issues you bring up amount to:
 
 1> no L/R-value usage (++, +=, etc, use as an inout or out arg)
 2> they can lead to hard to find reference semantics issues
 3> syntax problems with properties retuning delegates
 4> not interchangeable with fields
 #1 can be fixed without explicit properties
 


same as above
 
 #2 is not at all a problem in my book
 

Don't tell me it isn't a problem!

It's not a problem with /properties/. dropping properties compleaty wouldn't remove this type of isses. It might make some cases easyer to spot but nothing more. As to converting from a member to a property changing things, that is part of point #4.
 #4 this is a good point, however, as stated above, I don't like the
 proposed solution. Also, the proposed solution doesn't fix the issue
 because taking the address of a field is allowed, even with explicit
 properties, this wouldn't work
 

Suggestions are welcome and encouraged.

Nothing yet. IMHO, your proposed solution, while maybe appropriate for higher level languages, is not right for D. If I see a solution that solves these issues without cause to many of its own problems, I would be interested.
 As for the address of a field... perhaps if taking the address of a
 field returned a delegate... nah.
 This is somewhat of a corner case, but you've got me there, for now.
 I'd love to see someone come up with a slick solution to this.
 I should also note that C# didn't seem to have this problem with its
 explicit properties.  That is probably because in C#, using pointers
 was
 considered "unsafe" and done very infrequently.  It makes me want to
 bust out C# again and see what happens when one tries to take the
 address of a property, and I probably will at some point.
 Even if the addressing thing can't be fixed, I'd at least like to see
 the rest of the stuff get fixed.

I'll bet you can't. You can't use one for an out or ref argument (I just cheked) but you can use a member.
Aug 18 2007
parent reply Jason House <jason.james.house gmail.com> writes:
BCS wrote:
 I see your point and I strongly disagree. Under the covers, it IS a 
 function and I /don't/ want that hidden.

By the very virtue that D makes the syntax identical, it _is_ trying to hide that fact. Either properties must try to act like members or the usage of properties should not mirror members.
Aug 18 2007
parent BCS <ao pathlink.com> writes:
Reply to Jason,

 BCS wrote:
 
 I see your point and I strongly disagree. Under the covers, it IS a
 function and I /don't/ want that hidden.
 

to hide that fact. Either properties must try to act like members or the usage of properties should not mirror members.

Good point. To some extent it does. However, that just doesn't feel the same as Chad's suggestion. I'm not sure exactly why, but I thing it has something to do with the fact that currently D only hides the function'ness syntactically, but the proposal does so semantically.
Aug 18 2007