As an example let's say I have a type 'Window' that represents a win32 window. I'd like to be able to construct an instance of the type with some optional parameters that default to some reasonable settings and create the underlying win32 window.

I'd ideally like some syntax like this :-

auto window = Window(title = "My Window", width = 1000, fullscreen = true);

Assume that title, width, fullscreen are optional and if not specified there are defaults to use. And that there are many other settings than just these 3 that I've chosen to just use the default here.

I know that I can't do it like this is D but what is the best way to achieve this kind of thing? I can add properties and then do a specific "create" function to create the underlying win32 window once I'm done but that seems ugly.

auto window = Window();
window.title = "My Window";
window.width = 1000;
window.create();

This is ok, but I'm not so keen on separating the creation and construction like this.
Is there a better way that's not ugly?

Longer term, you're better off with the builder. Even with named parameters (2 DIP's are in the queue for adding it).

Creating windows is a very complex task that can balloon in scope.
Being able to hide it away in a separate type can be quite desirable if you want your windowing library to be actually useful in not just one simple case.

Of course that doesn't mean you couldn't hide that its there ;)

On Tuesday, 15 January 2019 at 11:26:50 UTC, rikki cattermole wrote:
> Longer term, you're better off with the builder.
Thanks for your reply. But what is the builder?


> Creating windows is a very complex task that can balloon in scope.

Well that was mostly just an example that I thought people could relate to more than my obscure real case :) But the principle is the same so the answer is likely too

On 16/01/2019 1:05 AM, John Burton wrote:
> On Tuesday, 15 January 2019 at 11:26:50 UTC, rikki cattermole wrote:
>> Longer term, you're better off with the builder.
> Thanks for your reply. But what is the builder?

https://en.wikipedia.org/wiki/Builder_pattern

One of the few OOP design patterns that I can agree with.

On Tuesday, 15 January 2019 at 12:15:41 UTC, rikki cattermole wrote:
> On 16/01/2019 1:05 AM, John Burton wrote:
>> On Tuesday, 15 January 2019 at 11:26:50 UTC, rikki cattermole wrote:
>>> Longer term, you're better off with the builder.
>> Thanks for your reply. But what is the builder?
>
> https://en.wikipedia.org/wiki/Builder_pattern
>
> One of the few OOP design patterns that I can agree with.

Ah right, that.
Thank you.
Hmm that would work.

On Tuesday, 15 January 2019 at 11:14:54 UTC, John Burton wrote:
> This is ok, but I'm not so keen on separating the creation and construction like this.
> Is there a better way that's not ugly?

You can make the constructor a template that takes a single struct of arbitrary, and inspects (at compile time) if it has fields with certain names and types. Then, when constructing, you feed that constructor a std.typecons.Tuple with named fields. Or alternatively, use a separate builder type that makes a good struct to feed for the window constructor.

The disadvantage is that you cannot link the constructor template directly for external programs. But for that, you define some sort of wrapper function that always takes all the parameters and then calls the template.

On Wednesday, 16 January 2019 at 11:21:53 UTC, Dukc wrote:
> a template that takes a single struct of arbitrary,

meant "of arbitrary type"

On Tuesday, 15 January 2019 at 11:14:54 UTC, John Burton wrote:
>
> auto window = Window();
> window.title = "My Window";
> window.width = 1000;
> window.create();
>

You can slightly modify it to the way APIs like DirectX or Vulkan do it.

auto windowinfo = WindowInfo();
windowinfo.title = "My Window";
windowinfo.width = 1000;

auto window = Window(windowinfo);

On Wednesday, 16 January 2019 at 11:21:53 UTC, Dukc wrote:
> On Tuesday, 15 January 2019 at 11:14:54 UTC, John Burton wrote:
>> This is ok, but I'm not so keen on separating the creation and construction like this.
>> Is there a better way that's not ugly?
>
> You can make the constructor a template that takes a single struct of arbitrary, and inspects (at compile time) if it has fields with certain names and types. Then, when constructing, you feed that constructor a std.typecons.Tuple with named fields. Or alternatively, use a separate builder type that makes a good struct to feed for the window constructor.
>
> The disadvantage is that you cannot link the constructor template directly for external programs. But for that, you define some sort of wrapper function that always takes all the parameters and then calls the template.

Thanks, I tried out the tuple approach and it works very well.
Constructing a tuple at the point of call with named fields works well, but looks a bit "ugly" to me but I might use it.
I think on balance that creating a separate builder struct that I can set the fields in and pass to the "real" constructor might be the way to go though for me.

On Tuesday, 15 January 2019 at 11:14:54 UTC, John Burton wrote:
> auto window = Window(title = "My Window", width = 1000, fullscreen = true);

In this particular case I would make the constructor take 3 parameters - title, width and height. Full screen is a rare functionality and shouldn't clutter the constructor, can it be set after the window is created?