Jump to page: 1 2 3
Thread overview
Properties don't behave like variables?
May 07, 2012
Mehrdad
May 07, 2012
Jonathan M Davis
May 07, 2012
Era Scarecrow
May 07, 2012
Mehrdad
May 07, 2012
Jonathan M Davis
May 07, 2012
Mehrdad
May 07, 2012
Andrej Mitrovic
May 07, 2012
Gor Gyolchanyan
May 07, 2012
Jacob Carlborg
May 07, 2012
Jacob Carlborg
May 07, 2012
Artur Skawina
May 07, 2012
Iain Buclaw
May 07, 2012
Artur Skawina
May 07, 2012
Iain Buclaw
May 07, 2012
Mehrdad
May 07, 2012
Michael
May 07, 2012
Mehrdad
May 07, 2012
Chris Cain
May 07, 2012
Jacob Carlborg
May 07, 2012
Jonathan M Davis
May 07, 2012
Chris Cain
May 08, 2012
Jacob Carlborg
May 14, 2012
Michael
May 14, 2012
Mehrdad
May 14, 2012
Mehrdad
May 15, 2012
Michael
Jul 21, 2012
Michael
May 07, 2012
Why doesn't this compile?

@property int foo() { return 1; }
@property void foo(int v) { }

void main()
{
	foo |= 2;
}
May 07, 2012
On Monday, May 07, 2012 04:05:20 Mehrdad wrote:
> Why doesn't this compile?
> 
> @property int foo() { return 1; }
> @property void foo(int v) { }
> 
> void main()
> {
> 	foo |= 2;
> }

Because unfortunately, properties aren't currently set up to be quite as advanced as that. Properties read like variables and write like variables, but they don't read and write at the same time like variables do.

foo = foo | 2;

would work, because each property usage is translated into a single call to a function, but

foo |= 2;

doesn't, because it would require it be translated into

foo = foo | 2;

and then translated into calls to the property functions. I'd definitiely argue that it should work that way, but D's properties are simplistic enough that they don't currently. There may or may not be an enhancement request for it, but if not, then there probably should be.

Another example which is brought up from time to time is

++foo;

It doesn't work either, and for the same reasons.

- Jonathan M Davis
May 07, 2012
On Monday, 7 May 2012 at 02:05:21 UTC, Mehrdad wrote:
> Why doesn't this compile?
>
> @property int foo() { return 1; }
> @property void foo(int v) { }
>
> void main()
> {
> 	foo |= 2;
> }

 Off hand I would say because it doesn't go to anything (Open the box... What do you mean what box? That invisible one over there can't you see it!?)...

 Might be better to ask in D.learn, I try and refrain topics unless it actually is in more depth or requires advanced answers.

Consider...

@property int sq(int x) { return x * x;}

void main(){
  int x = 5;
  writeln(x.sq); //should print 25
}
May 07, 2012
@Era Scarecrow: I don't understand your response.


@Jon: Should I submit an enhancement?
May 07, 2012
On Monday, May 07, 2012 04:52:32 Mehrdad wrote:
> @Jon: Should I submit an enhancement?

If you can't find an existing one. I haven't found one.

- Jonathan M Davis
May 07, 2012
On Monday, 7 May 2012 at 03:06:12 UTC, Jonathan M Davis wrote:
> On Monday, May 07, 2012 04:52:32 Mehrdad wrote:
>> @Jon: Should I submit an enhancement?
>
> If you can't find an existing one. I haven't found one.
>
> - Jonathan M Davis

Ok thanks.

http://d.puremagic.com/issues/show_bug.cgi?id=8056
May 07, 2012
On 5/7/12, Mehrdad <wfunction@hotmail.com> wrote:
> Why doesn't this compile?

Upboat: http://d.puremagic.com/issues/show_bug.cgi?id=8006

Maybe the title could use some work though.
May 07, 2012
I think the properties could be much more useful as a library solution.
I'm thinking a template, which generates a structure with all
necessary operators overloaded.
It would be much more flexible. The only downside would be absence of
syntax sugar.
It would work faster too in cases of opOpAssign, because opOpAssign is
generally faster then a combination of opAssign and opBinary.

On Mon, May 7, 2012 at 6:19 AM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> On Monday, May 07, 2012 04:05:20 Mehrdad wrote:
>> Why doesn't this compile?
>>
>> @property int foo() { return 1; }
>> @property void foo(int v) { }
>>
>> void main()
>> {
>>       foo |= 2;
>> }
>
> Because unfortunately, properties aren't currently set up to be quite as advanced as that. Properties read like variables and write like variables, but they don't read and write at the same time like variables do.
>
> foo = foo | 2;
>
> would work, because each property usage is translated into a single call to a function, but
>
> foo |= 2;
>
> doesn't, because it would require it be translated into
>
> foo = foo | 2;
>
> and then translated into calls to the property functions. I'd definitiely argue that it should work that way, but D's properties are simplistic enough that they don't currently. There may or may not be an enhancement request for it, but if not, then there probably should be.
>
> Another example which is brought up from time to time is
>
> ++foo;
>
> It doesn't work either, and for the same reasons.
>
> - Jonathan M Davis



-- 
Bye,
Gor Gyolchanyan.
May 07, 2012
On Sun, 06 May 2012 22:05:20 -0400, Mehrdad <wfunction@hotmail.com> wrote:

> Why doesn't this compile?
>
> @property int foo() { return 1; }
> @property void foo(int v) { }
>
> void main()
> {
> 	foo |= 2;
> }

It's like this in C#.

I can't decide whether I like it better in D or C#.  Clearly the compiler lowering of foo |= 2 to foo = foo | 2 would be benficial in terms of less code to write.

But I also like having control over how properties can implement operators.  For example, the above is two function calls, but it may be easier/more efficient written as one.  The issue is, how do you do that?

The current definition syntax doesn't lend itself well to extension...

-Steve
May 07, 2012
On 2012-05-07 14:43, Steven Schveighoffer wrote:

> It's like this in C#.
>
> I can't decide whether I like it better in D or C#. Clearly the compiler
> lowering of foo |= 2 to foo = foo | 2 would be benficial in terms of
> less code to write.
>
> But I also like having control over how properties can implement
> operators. For example, the above is two function calls, but it may be
> easier/more efficient written as one. The issue is, how do you do that?
>
> The current definition syntax doesn't lend itself well to extension...
>
> -Steve

If an operator is overloaded use that single function, otherwise do a rewirte.

-- 
/Jacob Carlborg
« First   ‹ Prev
1 2 3