www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Is there a nice syntax to achieve optional named parameters?

reply John Burton <john.burton jbmail.com> writes:
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?
Jan 15
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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 ;)
Jan 15
parent reply John Burton <john.burton jbmail.com> writes:
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
Jan 15
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
Jan 15
parent John Burton <john.burton jbmail.com> writes:
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.
Jan 15
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
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.
Jan 16
next sibling parent Dukc <ajieskola gmail.com> writes:
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"
Jan 16
prev sibling parent John Burton <john.burton jbmail.com> writes:
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.
Jan 16
prev sibling next sibling parent JN <666total wp.pl> writes:
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);
Jan 16
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
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?
Jan 16
parent reply John Burton <john.burton jbmail.com> writes:
On Wednesday, 16 January 2019 at 14:59:01 UTC, Kagamin wrote:> 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?
Well window was just an example really, my real use case is a similar object that needs a lot of configuration where mostly the default works but you might want to override, and the config is needed to create the object in the first place. For this example you are right though, and it may be that I'm overthinking the whole thing.
Jan 17
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 17, 2019 at 10:29:13AM +0000, John Burton via Digitalmars-d-learn
wrote:
[...]
 Well window was just an example really, my real use case is a similar
 object that needs a lot of configuration where mostly the default
 works but you might want to override, and the config is needed to
 create the object in the first place.
[...] When I encounter similar situations in my code, my go-to solution is to use a struct with default field values as a configuration object that you pass to the ctor. You can either pass .init to the ctor to get default behavior, or declare an instance of the struct and customize as you see fit before handing it to the ctor. --T
Jan 17
prev sibling next sibling parent reply SrMordred <patric.dexheimer gmail.com> writes:
On Tuesday, 15 January 2019 at 11:14:54 UTC, John Burton wrote:
 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?
Let me throw this idea here: struct Config { string title; int width; } struct Window { this(Config config) { //use static foreach magic to set everything :P } } auto NewWindow( alias code )() { mixin("Config config = {"~code~"};"); return Window(config); } //usage: auto a = NewWindow!q{ title : "MainTitle" }; auto b = NewWindow!q{ title : "MainTitle", width : 800 }; auto c = NewWindow!q{ width : 1000 }; auto d = NewWindow!q{}; :)
Jan 16
next sibling parent John Burton <john.burton jbmail.com> writes:
On Thursday, 17 January 2019 at 01:43:42 UTC, SrMordred wrote:
 On Tuesday, 15 January 2019 at 11:14:54 UTC, John Burton wrote:
 [...]
Let me throw this idea here: struct Config { string title; int width; } struct Window { this(Config config) { //use static foreach magic to set everything :P } } auto NewWindow( alias code )() { mixin("Config config = {"~code~"};"); return Window(config); } //usage: auto a = NewWindow!q{ title : "MainTitle" }; auto b = NewWindow!q{ title : "MainTitle", width : 800 }; auto c = NewWindow!q{ width : 1000 }; auto d = NewWindow!q{}; :)
Oh that's interesting!
Jan 17
prev sibling next sibling parent reply Matheus <stop spam.com> writes:
On Thursday, 17 January 2019 at 01:43:42 UTC, SrMordred wrote:
 Let me throw this idea here:
...
I usually do this too, I like to use struct and then in another language I use reflection do optimize binding. Anyway I understood all your code, except for this "alias code"
 auto NewWindow( alias code )()
 {
 	mixin("Config config = {"~code~"};");
 	return Window(config);
 }
Looking on specs: https://dlang.org/spec/declaration.html#alias "AliasDeclarations create a symbol that is an alias for another type, and can be used anywhere that other type may appear." So with your example imagine this: foo(alias x){} foo("a"); foo(1); 'x' will be string one time and integer another? Or there is something that I'm missing. Matheus.
Jan 17
parent reply SrMordred <patric.dexheimer gmail.com> writes:
On Thursday, 17 January 2019 at 12:11:02 UTC, Matheus wrote:
 foo(alias x){}

 foo("a");
 foo(1);

 'x' will be string one time and integer another? Or there is 
 something that I'm missing.

 Matheus.
Yes, but there is a mistake there: alias is part of the template: foo(alias x)(){} //note extra parens than u call like an template: foo!"a"; //equivalent = foo!("a")(); foo!1;
Jan 17
parent Matheus <stop spam.com> writes:
On Thursday, 17 January 2019 at 16:55:33 UTC, SrMordred wrote:
 Yes, but there is a mistake there:
 alias is part of the template:

 foo(alias x)(){} //note extra parens

 than u call like an template:

 foo!"a"; //equivalent = foo!("a")();
 foo!1;
I see now and thanks. Matheus.
Jan 17
prev sibling next sibling parent kdevel <kdevel vogtner.de> writes:
On Thursday, 17 January 2019 at 01:43:42 UTC, SrMordred wrote:
 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();
[...]
 Is there a better way that's not ugly?
[...]
 //usage:
 auto a = NewWindow!q{ title : "MainTitle" };
 auto b = NewWindow!q{ title : "MainTitle", width : 800 };
 auto c = NewWindow!q{ width : 1000 };
 auto d = NewWindow!q{};


 :)
Put a semicolon instead of the comma in the line "auto b ..." and compile.
Jan 17
prev sibling parent reply John Burton <john.burton jbmail.com> writes:
On Thursday, 17 January 2019 at 01:43:42 UTC, SrMordred wrote:

 struct Config
 {
 	string title;
 	int width;
 }

 struct Window
 {
 	this(Config config)
It likely is a bad idea for a small struct like this but if it was much bigger would it makes sense to write this as :- this(const ref Config config) Which is what you might do in C++ or does D handle this differently?
Jan 18
next sibling parent evilrat <evilrat666 gmail.com> writes:
On Friday, 18 January 2019 at 09:39:31 UTC, John Burton wrote:
 On Thursday, 17 January 2019 at 01:43:42 UTC, SrMordred wrote:

 struct Config
 {
 	string title;
 	int width;
 }

 struct Window
 {
 	this(Config config)
It likely is a bad idea for a small struct like this but if it was much bigger would it makes sense to write this as :- this(const ref Config config) Which is what you might do in C++ or does D handle this differently?
You'd better profile and only then act. Seriously, whatever you know and familiar with in C++ might not work with D, you'll just end up with C++'ish code that just happens to be written in D. D is not C++, and such premature optimizations might cause more harm if applied on occassion or out of habit. IIRC D structs are all movable, so doing const refs here and there or using writing to ref parameter instead normal return(RVO) is likely bad for your code. D has its own ABI, it's not even compatible with C++, so when you pass structs by value it may or may not produce similar asm as C++ compilers does. When struct contains strings/arrays they are anyway managed by GC(unless you allocated it on your own), but this is something that more seasoned D users can explain in better details and cleaner explanation than me, if it means anything at all. Even without all this, do you really want to mess up your codebase with implementation details about how it should do it, or write clean (self)documented code? Is it really going to be a bottleneck in your program? Passing one big struct at widget's creation on program startup and some rare events really going to kill performance? Why not just write working code first and then identify bottlenecks and optimize when it absolutely ultimately necessary? Btw I don't remember much ref parameters in phobos, just look at it... I found only 4 ref consts it in std.file, 3 in std.array, other modules more likely to have them in comparison operators(I have no idea why, to not introduce potential RVO case?) and in unit tests for testing correct behavior. Again, D is not C++, what might work or even considered "good practice" there may or may not work here. So just profile it!
Jan 18
prev sibling next sibling parent Kagamin <spam here.lot> writes:
On Friday, 18 January 2019 at 09:39:31 UTC, John Burton wrote:
 It likely is a bad idea for a small struct like this but if it 
 was much bigger would it makes sense to write this as :-

 	this(const ref Config config)

 Which is what you might do in C++ or does D handle this 
 differently?
For big Config struct it probably doesn't matter, but ref parameters don't accept rvalues.
Jan 18
prev sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Fri, 18 Jan 2019 09:39:31 +0000, John Burton wrote:
 On Thursday, 17 January 2019 at 01:43:42 UTC, SrMordred wrote:
 
 struct Config {
 	string title;
 	int width;
 }

 struct Window {
 	this(Config config)
It likely is a bad idea for a small struct like this but if it was much bigger would it makes sense to write this as :- this(const ref Config config) Which is what you might do in C++ or does D handle this differently?
Creating a window is the dominating cost here. If you're creating enough windows that copying them is a problem, you're doing something seriously weird and it might be more productive to step back and think about that than to switch to const ref.
Jan 18
prev sibling parent reply Zenw <zero.error.no.warning gmail.com> writes:
On Tuesday, 15 January 2019 at 11:14:54 UTC, John Burton wrote:
 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.

 [...]
how about this auto With(string code,T)(T value) { with(value) { mixin(code ~";"); } return value; } auto window = Window().With!q{title = "My window",width = 800,fullscreen = true};
Jan 19
parent reply Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Saturday, 19 January 2019 at 14:26:31 UTC, Zenw wrote:
 On Tuesday, 15 January 2019 at 11:14:54 UTC, John Burton wrote:
 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.

 [...]
how about this auto With(string code,T)(T value) { with(value) { mixin(code ~";"); } return value; } auto window = Window().With!q{title = "My window",width = 800,fullscreen = true};
The problem with using string mixins like that is when you want to use some local variable: int width = getWidth(); auto window = Window().With!q{width = width}; This would work: struct Window { string title; int width; bool fullscreen; } auto With(T, Args...)(T ctx, Args args) { static foreach (i; 0..Args.length) { mixin("ctx."~Args[i].name~" = args[i].value;"); } return ctx; } struct args { static opDispatch(string _name, T)(T value) { struct Result { enum name = _name; T value; } return Result(value); } } unittest { auto window = Window().With(args.title = "My window", args.width = 800, args.fullscreen = true); assert(window.title == "My window"); assert(window.width == 800); assert(window.fullscreen == true); } However, I don't see that there's all that much gain compared to just assigning the fields the normal way. -- Simen
Jan 20
parent John Burton <john.burton jbmail.com> writes:
On Monday, 21 January 2019 at 07:57:58 UTC, Simen Kjærås wrote:
 On Saturday, 19 January 2019 at 14:26:31 UTC, Zenw wrote:
 On Tuesday, 15 January 2019 at 11:14:54 UTC, John Burton wrote:
 [...]
how about this auto With(string code,T)(T value) { with(value) { mixin(code ~";"); } return value; } auto window = Window().With!q{title = "My window",width = 800,fullscreen = true};
The problem with using string mixins like that is when you want to use some local variable: int width = getWidth(); auto window = Window().With!q{width = width}; This would work: struct Window { string title; int width; bool fullscreen; } auto With(T, Args...)(T ctx, Args args) { static foreach (i; 0..Args.length) { mixin("ctx."~Args[i].name~" = args[i].value;"); } return ctx; } struct args { static opDispatch(string _name, T)(T value) { struct Result { enum name = _name; T value; } return Result(value); } } unittest { auto window = Window().With(args.title = "My window", args.width = 800, args.fullscreen = true); assert(window.title == "My window"); assert(window.width == 800); assert(window.fullscreen == true); } However, I don't see that there's all that much gain compared to just assigning the fields the normal way. -- Simen
Thanks everyone for your advice on this. I'm decided to just use a parameter structure to pass in. Works well and everyone can understand it. The question was really just does D offer a nicer way and the answer appears to be "not really". But the original approach isn't bad anyway.
Jan 21