Jump to page: 1 2
Thread overview
D Properties when?
Dec 14, 2023
Hipreme
Dec 14, 2023
jmh530
Dec 14, 2023
Timon Gehr
Dec 15, 2023
Dom DiSc
Dec 17, 2023
Timon Gehr
Dec 14, 2023
ryuukk_
Dec 14, 2023
IGotD-
Dec 14, 2023
Max Samukha
Dec 14, 2023
Timon Gehr
Dec 15, 2023
Hipreme
Dec 20, 2023
Quirin Schroll
Dec 20, 2023
ryuukk_
Dec 14, 2023
H. S. Teoh
December 14, 2023

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.

December 14, 2023

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:

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);
}
December 14, 2023
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.
December 14, 2023

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:

int my_dumb_function() => 1 + 1;

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

i don't understand why people want D to be a copy pasta of C#

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
December 14, 2023

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

>

i don't understand why people want D to be a copy pasta of C#

Data binding with properties in C# rocks big time, and it can be a variable or function. Love it.

December 14, 2023

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

>

it's the same nitpicking as:

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?

December 14, 2023
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.
December 14, 2023
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!
December 15, 2023

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:

int my_dumb_function() => 1 + 1;

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

i don't understand why people want D to be a copy pasta of C#

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.

December 15, 2023
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.
« First   ‹ Prev
1 2