www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D Properties when?

reply Hipreme <msnmancini hotmail.com> writes:
This is no news in the programming world, yet, we still don't 
have it.

This is very important for I can define a good API in which I 
could increase my engine performance.
With that, I could implement fields with dirty flags and not make 
the API looks dirty (no pun intended).


Think of an object with X and Y position. I want to be able to 
when its value changes, it sets a dirty flag to true. The problem 
is that I'm unable to do `X+= 50` after that. I need to do `X = X 
+ 50`, this is not news but still makes the API inconsistent and 
more verbose.
I don't care how this is implemented, I only want this some day 
to not make it look ugly.
Dec 14 2023
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 14 December 2023 at 18:08:52 UTC, Hipreme wrote:

 This is no news in the programming world, yet, we still don't 
 have it.

 This is very important for I can define a good API in which I 
 could increase my engine performance.
 With that, I could implement fields with dirty flags and not 
 make the API looks dirty (no pun intended).


 Think of an object with X and Y position. I want to be able to 
 when its value changes, it sets a dirty flag to true. The 
 problem is that I'm unable to do `X+= 50` after that. I need to 
 do `X = X + 50`, this is not news but still makes the API 
 inconsistent and more verbose.
 I don't care how this is implemented, I only want this some day 
 to not make it look ugly.


I'm not entirely sure what you mean, but what about something 
like this:

```d
import std.stdio: writeln;

struct Direction
{
     int x;
     alias x this;
     private bool _dirty;
     void opOpAssign(string op: "+")(int rhs) {
         x += rhs;
         _dirty = true;
     }
}

struct Foo
{
     Direction x;
     Direction y;
     this(int x, int y) {
      	this.x = Direction(x);
         this.y = Direction(y);
     }
}

void main()
{
     auto f = Foo(1, 2);
     f.x += 50;
     writeln(f.x._dirty);
     writeln(f.y._dirty);
}
```
Dec 14 2023
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/14/23 19:08, Hipreme wrote:

 This is no news in the programming world, yet, we still don't have it.
 
 This is very important for I can define a good API in which I could 
 increase my engine performance.
 With that, I could implement fields with dirty flags and not make the 
 API looks dirty (no pun intended).
 
 
 Think of an object with X and Y position. I want to be able to when its 
 value changes, it sets a dirty flag to true. The problem is that I'm 
 unable to do `X+= 50` after that. I need to do `X = X + 50`, this is not 
 news but still makes the API inconsistent and more verbose.
 I don't care how this is implemented, I only want this some day to not 
 make it look ugly.


https://wiki.dlang.org/DIP24

Doing those right is a breaking change, so maybe with editions.
Dec 14 2023
parent reply Dom DiSc <dominikus scherkl.de> writes:
On Thursday, 14 December 2023 at 18:52:03 UTC, Timon Gehr wrote:

 https://wiki.dlang.org/DIP24

 Doing those right is a breaking change, so maybe with editions.


Sorry, this would break only code that was already broken. So 
should not hinder us to implement it.
Dec 15 2023
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/15/23 13:15, Dom DiSc wrote:

 On Thursday, 14 December 2023 at 18:52:03 UTC, Timon Gehr wrote:

 https://wiki.dlang.org/DIP24

 Doing those right is a breaking change, so maybe with editions.


 
 Sorry,


No worries, it does not offend me.


 this would break only code that was already broken.


Personally, I am all for breaking code, but my understanding is we are 
no longer engaging in that until editions are set up.


 So should not hinder us to implement it.


I think the main hindrances to implementing it are:
- You need to understand what is the correct fix. (I think it is obvious 
but somehow people still seem to have different views on this.)
- You need to figure out the relevant DMD code (which could be _a lot_ 
of separate locations) and actually fix it.
- The changes are unlikely to make it in before editions, at which point 
you will have to update the changes in order to be compatible with editions.

But by all means, go ahead. Just be prepared for a bit of a headache 
while getting it to work and to then repeatedly rebase highly sprinkled 
out changes for a significant duration of time and/or to reimplement it 
multiple times.
Dec 17 2023
prev sibling next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Thursday, 14 December 2023 at 18:08:52 UTC, Hipreme wrote:

 This is no news in the programming world, yet, we still don't 
 have it.

 This is very important for I can define a good API in which I 
 could increase my engine performance.
 With that, I could implement fields with dirty flags and not 
 make the API looks dirty (no pun intended).


 Think of an object with X and Y position. I want to be able to 
 when its value changes, it sets a dirty flag to true. The 
 problem is that I'm unable to do `X+= 50` after that. I need to 
 do `X = X + 50`, this is not news but still makes the API 
 inconsistent and more verbose.
 I don't care how this is implemented, I only want this some day 
 to not make it look ugly.


a function is a function, a field is a field

mixing the two is a bad idea, you think you get a field, but 
under the food it does weird stuff

`properties` is nitpicking, making things more confusing that 
they should be

it's the same nitpicking as:

```D
int my_dumb_function() => 1 + 1;
```

this stuff is useless, takes development time to implement, and 
produce 0 value, literally confusing and useless



i'd rather the language focus on what _really_ matter, areas 
where D falls behind serious competition (Rust/Zig/Odin/Nim/Swift)

- native tuple: multiple return value
- tagged union: improved enum/union
- pattern matching: improved switch
Dec 14 2023
next sibling parent IGotD- <nise nise.com> writes:
On Thursday, 14 December 2023 at 19:49:35 UTC, ryuukk_ wrote:





a variable or function. Love it.
Dec 14 2023
prev sibling next sibling parent Max Samukha <maxsamukha gmail.com> writes:
On Thursday, 14 December 2023 at 19:49:35 UTC, ryuukk_ wrote:


 it's the same nitpicking as:

 ```D
 int my_dumb_function() => 1 + 1;
 ```

 this stuff is useless, takes development time to implement, and 
 produce 0 value, literally confusing and useless


It is no more useless than any other syntactic convenience. And 
what is confusing about it?
Dec 14 2023
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/14/23 20:49, ryuukk_ wrote:

 
 a function is a function, a field is a field


Unnecessary distinction, making compiler complain for no reason, taking 
up development time.
Dec 14 2023
prev sibling next sibling parent reply Hipreme <msnmancini hotmail.com> writes:
On Thursday, 14 December 2023 at 19:49:35 UTC, ryuukk_ wrote:

 On Thursday, 14 December 2023 at 18:08:52 UTC, Hipreme wrote:

 This is no news in the programming world, yet, we still don't 
 have it.

 This is very important for I can define a good API in which I 
 could increase my engine performance.
 With that, I could implement fields with dirty flags and not 
 make the API looks dirty (no pun intended).


 Think of an object with X and Y position. I want to be able to 
 when its value changes, it sets a dirty flag to true. The 
 problem is that I'm unable to do `X+= 50` after that. I need 
 to do `X = X + 50`, this is not news but still makes the API 
 inconsistent and more verbose.
 I don't care how this is implemented, I only want this some 
 day to not make it look ugly.


 a function is a function, a field is a field

 mixing the two is a bad idea, you think you get a field, but 
 under the food it does weird stuff

 `properties` is nitpicking, making things more confusing that 
 they should be

 it's the same nitpicking as:

 ```D
 int my_dumb_function() => 1 + 1;
 ```

 this stuff is useless, takes development time to implement, and 
 produce 0 value, literally confusing and useless



 i'd rather the language focus on what _really_ matter, areas 
 where D falls behind serious competition 
 (Rust/Zig/Odin/Nim/Swift)

 - native tuple: multiple return value
 - tagged union: improved enum/union
 - pattern matching: improved switch


Tagged Union can easily be implemented as library solutions, and 
ought to take a lot more time than implementing a simple feature 
which brings real value to development. About the others, I could 
not care less, the library tuples+aliasseq are just enough for 
me, tuples are a lot more confusing and code that overuse it is 
*always* bad. I want real productivity features.
Dec 15 2023
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 16/12/2023 12:41 AM, Hipreme wrote:

 I want real productivity features.


Tuples can be productivity features.

Between them, sumtypes and our excellent CT introspection capabilities, 
you can write up the data representation for some web form and have it 
generate it in a very short time frame.

Tuples are a key data representation in mathematics everything devolves 
to them, it'll help us in some surprising ways.
Dec 15 2023
prev sibling parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Thursday, 14 December 2023 at 19:49:35 UTC, ryuukk_ wrote:




Noted.


 i'd rather the language focus on what _really_ matter, areas 
 where D falls behind serious competition 
 (Rust/Zig/Odin/Nim/Swift)

 - native tuple: multiple return value
 - tagged union: improved enum/union
 - pattern matching: improved switch


This is funny now because native tuples and pattern matching are 

proposal](https://github.com/dotnet/csharplang/blob/main/proposals/disc


doesn’t have it would be plain wrong.)
Dec 20 2023
parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Wednesday, 20 December 2023 at 17:28:48 UTC, Quirin Schroll 
wrote:

 On Thursday, 14 December 2023 at 19:49:35 UTC, ryuukk_ wrote:




 Noted.


 i'd rather the language focus on what _really_ matter, areas 
 where D falls behind serious competition 
 (Rust/Zig/Odin/Nim/Swift)

 - native tuple: multiple return value
 - tagged union: improved enum/union
 - pattern matching: improved switch


 This is funny now because native tuples and pattern matching 

 proposal](https://github.com/dotnet/csharplang/blob/main/proposals/disc


doesn’t have it would be plain wrong.)


 too.


Java as well, they are all trying to catch up to the real 
competition, let's not match people who want to catch up, let's 
lead instead, hence my comment

If i had interests in compilers, i would have sent various PRs 
already, alas, i'm only interested in working on my game
Dec 20 2023
prev sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Dec 14, 2023 at 06:08:52PM +0000, Hipreme via Digitalmars-d wrote:
[...]

 Think of an object with X and Y position. I want to be able to when
 its value changes, it sets a dirty flag to true. The problem is that
 I'm unable to do `X+= 50` after that. I need to do `X = X + 50`, this
 is not news but still makes the API inconsistent and more verbose.

 I don't care how this is implemented, I only want this some day to not
 make it look ugly.


Just add the appropriate opOpAssign overload.  Use templates to reduce
the boilerplate to a minimum (this is why D's operator overloads are
templates taking the operator as a CT string parameter, as opposed to
forcing you to write 10 overloads to support 10 combinations of
operators).


T

-- 
IBM = I'll Buy Microsoft!
Dec 14 2023