www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - alias this doesn't work for properties.

reply "JS" <js.mdnq gmail.com> writes:
http://dpaste.dzfl.pl/0c923861

class A
{
     double x;
      property double X() { return x; }
      property double X(double v) { return x = v; }
     alias X this;
}

class B
{
     A a;
      property A Y() { return a; }
      property A Y(A v) { return a = v; }
}


void main()
{
	B b = new B();
	b.Y = 3;
}

error not a property of b.Y



adding refs to the returns of the getters allows the code to work 
but only getters are called(hence the need for refs).

Please allow alias this to work with overloaded functions. 
(specifically properties, b.Y = 3; is not b.Y() = 3 but b.Y(3);)
Aug 01 2013
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 1 August 2013 at 20:42:08 UTC, JS wrote:

 http://dpaste.dzfl.pl/0c923861

 class A
 {
     double x;
      property double X() { return x; }
      property double X(double v) { return x = v; }
     alias X this;
 }

 class B
 {
     A a;
      property A Y() { return a; }
      property A Y(A v) { return a = v; }
 }


 void main()
 {
 	B b = new B();
 	b.Y = 3;
 }

 error not a property of b.Y



 adding refs to the returns of the getters allows the code to 
 work but only getters are called(hence the need for refs).

 Please allow alias this to work with overloaded functions. 
 (specifically properties, b.Y = 3; is not b.Y() = 3 but b.Y(3);)


b.Y = 3 is rewritten as b.Y(3)

You are asking for an "int" to be be implicitly convertable to an 
"A", which isn't possible.
Aug 01 2013
next sibling parent reply "JS" <js.mdnq gmail.com> writes:
On Thursday, 1 August 2013 at 21:56:46 UTC, John Colvin wrote:

 On Thursday, 1 August 2013 at 20:42:08 UTC, JS wrote:

 http://dpaste.dzfl.pl/0c923861

 class A
 {
    double x;
     property double X() { return x; }
     property double X(double v) { return x = v; }
    alias X this;
 }

 class B
 {
    A a;
     property A Y() { return a; }
     property A Y(A v) { return a = v; }
 }


 void main()
 {
 	B b = new B();
 	b.Y = 3;
 }

 error not a property of b.Y



 adding refs to the returns of the getters allows the code to 
 work but only getters are called(hence the need for refs).

 Please allow alias this to work with overloaded functions. 
 (specifically properties, b.Y = 3; is not b.Y() = 3 but 
 b.Y(3);)


 b.Y = 3 is rewritten as b.Y(3)

 You are asking for an "int" to be be implicitly convertible to 
 an "A", which isn't possible.


This is wrong because

(cast(A)b.Y) = 3;

works.

b.Y(3) should work because A is aliased to double.

One of the issues is

b.Y(3)

The setter of B is never called.

You are right that b.Y(3) does not accept an int(or double) BUT 
this is a bug in the compiler because it should since 3 can be 
assigned to it. It's just that the compiler isn't smart enough to 
see this because of the way it calculates the assignment.

b.Y = 3 should do the same as b.a = 3 which should be the same as 
b.a.x = 3.

If you think about what the code is actually doing you will see 
it should be possible.


http://dpaste.dzfl.pl/ac376ca0
Aug 01 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 1 August 2013 at 22:23:40 UTC, JS wrote:

 This is wrong because

 (cast(A)b.Y) = 3;

 works.


That's an interesting case. cast(A)b.Y) is using the B getter 
property, which makes sense as, due to the cast, nothing in B can 
be called for the assigment.

So you have (in psuedo-code, all properties expanded as 
getY/setY):
     b.getY.castToA = 3;
wheras the previous example is:
     b.setY(3);

Neither are an int being implicitly converted to an A



 b.Y = 3 should do the same as b.a = 3 which should be the same 
 as b.a.x = 3.


Why that can't work:

struct A
{
     double x;
     alias x this;
}
struct B
{
     private A a;
      property A Y() { importantGetPrep(); return a; }
      property void Y(A v) { importantSetPrep(); a = v; }
}
void main()
{
     B b;
     b.Y = 3;  //cannot be a call to the setter as cannot convert 
3 to A .
               //cannot be a call to the getter followed by an 
assigment
               //as the assignment would then have no effect on b.a
               //due to value semantics.
               //cannot be anything else as it would bypass the
               //important*etPrep that must be called on all 
accesses
               //to B.a .
}

Putting functions like important*etPrep in properties are one of 
the main reasons why properties are useful, it would be a very 
bad idea to let them be circumvented by an implementation change 
in an internal struct.
Aug 01 2013
parent reply "JS" <js.mdnq gmail.com> writes:
On Thursday, 1 August 2013 at 23:51:38 UTC, John Colvin wrote:

 On Thursday, 1 August 2013 at 22:23:40 UTC, JS wrote:

 This is wrong because

 (cast(A)b.Y) = 3;

 works.


 That's an interesting case. cast(A)b.Y) is using the B getter 
 property, which makes sense as, due to the cast, nothing in B 
 can be called for the assigment.

 So you have (in psuedo-code, all properties expanded as 
 getY/setY):
     b.getY.castToA = 3;
 wheras the previous example is:
     b.setY(3);

 Neither are an int being implicitly converted to an A



 b.Y = 3 should do the same as b.a = 3 which should be the same 
 as b.a.x = 3.


 Why that can't work:

 struct A
 {
     double x;
     alias x this;
 }
 struct B
 {
     private A a;
      property A Y() { importantGetPrep(); return a; }
      property void Y(A v) { importantSetPrep(); a = v; }
 }
 void main()
 {
     B b;
     b.Y = 3;  //cannot be a call to the setter as cannot 
 convert 3 to A .
               //cannot be a call to the getter followed by an 
 assigment
               //as the assignment would then have no effect on 
 b.a
               //due to value semantics.
               //cannot be anything else as it would bypass the
               //important*etPrep that must be called on all 
 accesses
               //to B.a .
 }

 Putting functions like important*etPrep in properties are one 
 of the main reasons why properties are useful, it would be a 
 very bad idea to let them be circumvented by an implementation 
 change in an internal struct.


Ok, I don't know why you keep saying 3 cannot be "converted" to 
A. Do you

Realize that the ultimate goal is to assign 3 to x? 3 is an int 
and x is a double, there is no conversion issues here.


if I do a = 3; b.Y = a; then it is no problem.

The issue is that b.Y wants an A and ignores the alias, I think 
this is wrong behavior because when you alias A it is suppose to 
act like that type... in this case it doesn't. Simple as that.

I can see why in some cases it is suppose to act the way it does, 
e.g., what if B.Y uses other fields of A, you obviously can't use 
a int then. If this is the case a run time error or compile time 
error should occur.

In any case, I'll just overload the setter to accept double and 
be done with it. Arguing whether it is a flaw/limitation in D or 
a flaw/limitation in my thinking won't get the behavior I want.

Note, I can just use a setter on double then it will work fine. 
This is not the behavior I want though because I breaks the 
homogeneity of my code generation.

IMO, if the argument to a setter has an alias this, that type 
should also work for the argument. If the body of the setter uses 
things not in the aliased type then it it should be an error(in 
that case, you should overload the setter).

This way you get the logical behavior expected but can also 
handle the more complex case.

code:

struct A { value double; int x; alias this value; }

class B {

 property A prop(A v)
{
    A a = new A;
    a.value = a.x;  // error if v is double and no setter for 
double, remove line to make it work.
    return a;
}

// property A prop(double v) { ... } // specialize to prevent 
error for doubles


This way for simple properties one gets the expected behavior for 
alias this.
Aug 01 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 2 August 2013 at 00:36:19 UTC, JS wrote:

 Realize that the ultimate goal is to assign 3 to x?


A working solution is to just use opAssign. I think of alias this 
as being implicit cast to , whereas opAssign is implicit cast 
from (well, sort of, it only works on assignments, but there's 
also constructors you can do. Where it falls short of full 
implicit cast is stuff like function calls)

Anyway, try this:

class A
{
     double x;
      property double X() { return x; }
      property double X(double v) { return x = v; }
     alias X this;

     // new
     A opAssign(double rhs) { x = rhs; return this; }
}

Now:

         A a = new A();
         a = 3.14; // ok


Then the next question is b.Y = 3, which is one of those cases 
where it just isn't going to work like that. Y is pretty explicit 
about *wanting* an A, this isn't setting to an A, this would 
actually be implicit construction which is generally a no-no in D.

However, if you add:

      property A Y(double v) { return a = v; }

to class B, then it will compile, with a = v calling A.opAssign.



A cool thing about opAssign that aias this doesn't do right now 
is it can be templated or you can overload it, and handle a vast 
variety of types.
Aug 01 2013
prev sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Thursday, 1 August 2013 at 21:56:46 UTC, John Colvin wrote:

 You are asking for an "int" to be be implicitly convertable to 
 an "A", which isn't possible.


http://dpaste.dzfl.pl/c3cce6e2

import std.stdio;


class A
{
     double x;
      property double X() { writeln("From A.Get"); return x; }
      property double X(double v) { writeln("From A.Set"); x = v; 
return x; }
     alias X this;
	this(double val) { this.x = val; }
}

class B
{
	A a;
     A Y() { writeln("From B.Get"); return a; }
     A Y(A v ...) { writeln("From B.Set"); a =  v; return a; }

	this() { a = new A(0); }
}


void main()
{
	B b = new B();
	writeln(b.Y);
	b.Y = 3;
	writeln(b.Y);

	readln();
}
Aug 01 2013
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 2 August 2013 at 02:21:25 UTC, Maxim Fomin wrote:

 On Thursday, 1 August 2013 at 21:56:46 UTC, John Colvin wrote:

 You are asking for an "int" to be be implicitly convertable to 
 an "A", which isn't possible.


 http://dpaste.dzfl.pl/c3cce6e2

 import std.stdio;


 class A
 {
     double x;
      property double X() { writeln("From A.Get"); return x; }
      property double X(double v) { writeln("From A.Set"); x = 
 v; return x; }
     alias X this;
 	this(double val) { this.x = val; }
 }

 class B
 {
 	A a;
     A Y() { writeln("From B.Get"); return a; }
     A Y(A v ...) { writeln("From B.Set"); a =  v; return a; }

 	this() { a = new A(0); }
 }


 void main()
 {
 	B b = new B();
 	writeln(b.Y);
 	b.Y = 3;
 	writeln(b.Y);

 	readln();
 }


Ok... It doesn't work for structs though which is strange. The 
docs do only mention classes however.

That's not really an implicit conversion, it's an implicit 
contstruction. It's definitely not like alias this. (In your 
example the alias this is completely unused)

Does this have any bearing on the wider question? The variadic 
class construction syntax could be allowed for properties, with a 
restriction to only one argument passed.
Aug 02 2013
prev sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
I'm going to provide a reduced case for the issue you are having.

struct Foo {
     double x;
     alias x this;
}

void main() {
     Foo a;
     a = 8; // Alias this assignment
     assert(a.x == 8);
     fun(7); // What you want
}

void fun(Foo a) {
}

You're claiming that since Foo is requested to "be" a double 
calling fun(7) should just assign 7 to x.

What you're missing is that it is Foo which behaves like double, 
however fun(7) there is no Foo involved, it doesn't exist. You're 
actually requesting that a Foo is created, then to have an 
assignment of 7 to x of the new temporary Foo.

This is not a bug, it is by design. Alias this is sugar of type 
it is declared in not the type it is declared to.
Aug 01 2013
parent reply "JS" <js.mdnq gmail.com> writes:
On Friday, 2 August 2013 at 01:46:28 UTC, Jesse Phillips wrote:

 I'm going to provide a reduced case for the issue you are 
 having.

 struct Foo {
     double x;
     alias x this;
 }

 void main() {
     Foo a;
     a = 8; // Alias this assignment
     assert(a.x == 8);
     fun(7); // What you want
 }

 void fun(Foo a) {
 }

 You're claiming that since Foo is requested to "be" a double 
 calling fun(7) should just assign 7 to x.

 What you're missing is that it is Foo which behaves like 
 double, however fun(7) there is no Foo involved, it doesn't 
 exist. You're actually requesting that a Foo is created, then 
 to have an assignment of 7 to x of the new temporary Foo.

 This is not a bug, it is by design. Alias this is sugar of type 
 it is declared in not the type it is declared to.



Um, but I'm not talking about a free function or member function 
but a property... they are suppose to be special else whats the 
point. They are suppose to wrap fields.

Because of this "design" you speak of, I can't use a double 
wrapped(essentially)  type because it is in an interface and I 
can't use a field in the interface.

What is the difference between

class A
{
     int x;
}

class A
{
     private int _x;
      property int x() { }
      property int x(int v) { }
}

? From the outside world there is suppose to be no difference. 
The point of properties is to wrap a type... yet I can't do 
that.... and also because A is an interface there is not even a 
fallback to the using a field to get it to work.

Anyways, this isn't headed anywhere... It's easy to sit back and 
try to analyze the situation without having ran into the problem 
directly.
Aug 01 2013
next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 2 August 2013 at 01:55:35 UTC, JS wrote:

 Anyways, this isn't headed anywhere... It's easy to sit back 
 and try to analyze the situation without having ran into the 
 problem directly.


Is it not headed anywhere? Are you not learning the design 
choices of D and why those choices where chosen over others? Are 
you not learning the limitations that will be placed on you so 
that in the future you can select a design which matches those 
limitations?

D has many flaws and it is missing polish in many places. You've 
been putting CTFE and other features through their pases, yet 
instead of feeling that your are learning something you feel that 
it "isn't headed anywhere?"

There is much bickering about what properties are, but one thing 
we know is they can not act exactly like fields. So you're 
expectations are off here, and I too am disappointed.
Aug 01 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 2 August 2013 at 01:55:35 UTC, JS wrote:

 On Friday, 2 August 2013 at 01:46:28 UTC, Jesse Phillips wrote:

 I'm going to provide a reduced case for the issue you are 
 having.

 struct Foo {
    double x;
    alias x this;
 }

 void main() {
    Foo a;
    a = 8; // Alias this assignment
    assert(a.x == 8);
    fun(7); // What you want
 }

 void fun(Foo a) {
 }

 You're claiming that since Foo is requested to "be" a double 
 calling fun(7) should just assign 7 to x.

 What you're missing is that it is Foo which behaves like 
 double, however fun(7) there is no Foo involved, it doesn't 
 exist. You're actually requesting that a Foo is created, then 
 to have an assignment of 7 to x of the new temporary Foo.

 This is not a bug, it is by design. Alias this is sugar of 
 type it is declared in not the type it is declared to.



 Um, but I'm not talking about a free function or member 
 function but a property... they are suppose to be special else 
 whats the point. They are suppose to wrap fields.

 Because of this "design" you speak of, I can't use a double 
 wrapped(essentially)  type because it is in an interface and I 
 can't use a field in the interface.

 What is the difference between

 class A
 {
     int x;
 }

 class A
 {
     private int _x;
      property int x() { }
      property int x(int v) { }
 }

 ? From the outside world there is suppose to be no difference.


In an ideal world, perhaps. There has been a huge amount of 
discussion about properties here before and no solution is 
perfect.
Aug 02 2013
prev sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Friday, 2 August 2013 at 01:55:35 UTC, JS wrote:

 What is the difference between

 class A
 {
     int x;
 }

 class A
 {
     private int _x;
      property int x() { }
      property int x(int v) { }
 }

 ? From the outside world there is suppose to be no difference.


In the first case other modules can create a mutable pointer to 
the field x. In the second case other modules cannot create any 
pointer to field _x.
Aug 02 2013