Factory Methods about dunet HOT 6 CLOSED

Preliminary PR for this here: #33

from dunet.

I think this is a great idea. It would also work nicely when we add generic support since we cannot infer generic types with constructors.

from dunet.

I think #17 addresses this use case with a more superior implementation due to more control over the union members' types. What do you think @mumby0168 ?

from dunet.

I think #17 addresses this use case with a more superior implementation due to more control over the union members' types. What do you think @mumby0168 ?

Hi yes I like this, no reason the root record, the Result in the example cannot contain factory methods also. I.e Results.Ok() with the need of the new keyword, it could follow the same pattern with a bool to indicate you want the extra methods generating.

What do you think?

from dunet.

Hi yes I like this, no reason the root record, the Result in the example cannot contain factory methods also. I.e Results.Ok() with the need of the new keyword, it could follow the same pattern with a bool to indicate you want the extra methods generating.

What do you think?

I'm having a hard time seeing a generated factory method like Result.Ok() playing nicely with #17 also providing a way to instantiate that same union member with new Result.Ok() or Result.NewOk() due to name collisions. I'm inclined to prioritize the implementation of #17, and then reassessing how we feel about this issue after that.

from dunet.

After some more analysis, I'm going to defer this feature for the following reasons:

• The ability of users to write Foo.NewThing() rather than new Foo.Thing() is not worth the increase in complexity and potential maintenance burden to this library.
• Source generators already have a steep learning curve, due to a lot of hidden/non-explicit behavior. I believe a successful source generator should do as much as it can to minimize such behavior and take an explicit approach whenever possible. This feature runs counter to that philosophy.
• With #28 on the docket, constructors and factory methods will not be necessary for most use cases. This is because users will be able to assign inner union values directly to the union type. This will bring Dunet unions in line with most other language's DU implementations and effectively obsolete constructors and factory methods. For example:

// No need for constructor or factory methods to instantiate union values.
StringOrNumber str = "foo";
StringOrNumber num = 123;

[Union]
partial record StringOrNumber
{
    partial record Str(string Value);
    partial record Num(double Value);
}

If the community remains interested in this feature, I would whole-heartedly support a separate package containing this functionality. I'd also be glad to link to it from Dunet's readme if that becomes the case.

from dunet.