Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Tuesday, 22 May 2018 at 14:56:52 UTC, Ethan wrote: Repeat ad infinitum for each slightly different configuration you want. I always make the point of programmers being lazy by definition, and not being able to do something as simple as declare a type with a single statement is an clear example of reducing usability - which is a critical consideration the lazier a programmer is. This is the place where an editor could greatly improve productivity. Writing the parameterized instantiation of `enum option = Option(foo: true, bar: 5 ..);` and just being able to press a hotkey in a code editor and have the type automagically generated for you would nullify this benefit and at thesame time giving you all benefits of a struct. It even allows you to later add in some specific kind of initialization of these variables whitout much hastle. This is something i really miss in D. :/
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Tuesday, 22 May 2018 at 15:25:47 UTC, Jonathan M Davis wrote: Honestly, I hate named argumts in general. This situation is one of the few places I've ever run into where I thought that they made any sense. [snip] It's quite literally the only reason I ever want named arguments.
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Tuesday, May 22, 2018 14:53:50 Jacob Carlborg via Digitalmars-d wrote:
> On Tuesday, 22 May 2018 at 11:08:13 UTC, Jonathan M Davis wrote:
> > That's basically what dxml does except that it takes advantage
> > of the fact that each member is a different type (because each
> > is a differnt instance of std.typecons.Flag) so that it can
> > have a variadic function which takes any of the arguments in
> > any order. e.g.
> >
> > enum config = makeConfig(SkipComments.yes, SplitOnEmpty.yes);
> > auto range = parseXML!config(xml);
> >
> > or
> >
> > auto range = parseXML!(makeConfig(SkipComments.yes,
> > SplitOnEmpty.yes))(xml);
>
> I don't see how that is any better.
>
> * It requires implementing `makeConfig`
> * It requires using std.typecons.Flag which I think is an ugly
> hack due to the lack of named arguments
> * It only supports boolean types
>
> By using a regular struct it's also possible to specify named
> arguments and in any order:
>
> struct Options
> {
> bool foo;
> int value;
> bool bar;
> string value2;
> }
>
> Options options = { value2: "asd", bar: true, foo: false };
>
> --
Honestly, I hate named argumts in general. This situation is one of the few
places I've ever run into where I thought that they made any sense. This
type of situation is one of the few where having a bunc of parameters and
setting only a few makes much sense. So, I tend forget that the syntax that
you used here even exists, and I actively avoid it when I do remember that
it exists. Regardless, I was just pointing out what I'd done with dxml,
since it seems to match the use case here. I'm certainly not arguing that
it's always better. I don't think that I'd ever use a solution though that
encouraged using the {} syntax for initializing a struct, since I wish that
it wasn't even in the language.
- Jonathan M Davis
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Monday, 21 May 2018 at 14:36:32 UTC, Jacob Carlborg wrote:
enum Options options = { foo: true, bar: false, a: 42, b:
"guess what this does" };
SomeObject!options o;
Yeah, so this is one reason why I went the parsing way.
enum Options Options1 = { foo: false, a: 5 };
SomeObject!Options1 object1;
enum Options Options2 = { foo: true, b: "Totally different" };
SomeObject!Options2 object2;
Repeat ad infinitum for each slightly different configuration you
want. I always make the point of programmers being lazy by
definition, and not being able to do something as simple as
declare a type with a single statement is an clear example of
reducing usability - which is a critical consideration the lazier
a programmer is.
(As mentioned earlier in the thread, template parameter naming
would make this entire thing irrelevant. As would being able to
inline initialise a struct with named variables.)
Still, there's a few other things going on with my method. The
EnumOptions class turns any enumeration in to a bitfield
(regardless of underlying type). My own bitfield object in
Binderoo does not have the limitations of std.bitmanip.bitfields
as the type it creates internally is a ubyte[Size] aligned and
padded out to byte boundaries. An enum declaration of any length
is thus kosher. So perhaps EnumBitfield is the better name for
the object. Using it in such a way is essentially more used to
change default behaviour more than specify behaviour to begin
with.
It's also an enabler. My Binderoo example at the bottom of my
original post has multiple parameters of multiple different
types. But what if I need to add more to it? Easy enough to add a
variable to an options structure, you might think. But what if I
need a tuple of types? Then the options structure becomes
templated to hold the tuple. And so on and so forth. Parsing
template parameters doesn't lock you in to such unintended design
pattern consequences.
Parsing parameters also solves a problem I come across a bit too
often - the desire to have multiple variable parameter sets as
template parameters. Using that light wrapper template method
also ensures that I can parse and sort parameters to cut down on
unnecessary template reinstantiation.
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Tuesday, 22 May 2018 at 11:08:13 UTC, Jonathan M Davis wrote:
That's basically what dxml does except that it takes advantage
of the fact that each member is a different type (because each
is a differnt instance of std.typecons.Flag) so that it can
have a variadic function which takes any of the arguments in
any order. e.g.
enum config = makeConfig(SkipComments.yes, SplitOnEmpty.yes);
auto range = parseXML!config(xml);
or
auto range = parseXML!(makeConfig(SkipComments.yes,
SplitOnEmpty.yes))(xml);
I don't see how that is any better.
* It requires implementing `makeConfig`
* It requires using std.typecons.Flag which I think is an ugly
hack due to the lack of named arguments
* It only supports boolean types
By using a regular struct it's also possible to specify named
arguments and in any order:
struct Options
{
bool foo;
int value;
bool bar;
string value2;
}
Options options = { value2: "asd", bar: true, foo: false };
--
/Jacob Carlborg
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Monday, May 21, 2018 14:07:45 Jacob Carlborg via Digitalmars-d wrote:
> On Monday, 21 May 2018 at 00:13:26 UTC, Ethan wrote:
> > Code for context:
> > https://github.com/GooberMan/binderoo/blob/master/binderoo_client/d/src/
> > binderoo/util/enumoptions.d
> >
> > Something struck me at DConf. I was watching the dxml talk and
> > hearing about all these things that weren't being implemented
> > for one reason or another. And I was thinking, "But what if I
> > want those things?" Being D, it'd be pretty easy to opt in to
> > them with template parameters and static if controlling what
> > code gets executed at runtime.
> >
> > But that brings up a bit of an annoying thing. Namely, the old
> > school way of doing such things:
> >
> > class SomeObject( bool option1, bool option2, Flags iHateBools
> > = Flags.Default, int
> > ohIDontWantThisToBeDefaultedButRefactoringSucks = -1 )
> > {
> > }
> >
> > Pretty obnoxious design pattern.
> >
> > But we're in D. We can do much better. It makes sense to do the
> > following:
> >
> > class SomeObject( LooseOptions... )
> > {
> > }
>
> Unless I'm missing something we can do a lot better in D :
>
> struct Options
> {
> bool foo;
> bool bar;
> int a;
> string b;
> }
>
> class SomeObject(Options options)
> {
> static if (options.foo)
> {
> }
> }
>
> No magic templates or anything fancy.
>
> --
That's basically what dxml does except that it takes advantage of the fact
that each member is a different type (because each is a differnt instance of
std.typecons.Flag) so that it can have a variadic function which takes any
of the arguments in any order. e.g.
enum config = makeConfig(SkipComments.yes, SplitOnEmpty.yes);
auto range = parseXML!config(xml);
or
auto range = parseXML!(makeConfig(SkipComments.yes, SplitOnEmpty.yes))(xml);
http://jmdavisprog.com/docs/dxml/0.3.2/dxml_parser.html#.Config
http://jmdavisprog.com/docs/dxml/0.3.2/dxml_parser.html#.makeConfig
http://jmdavisprog.com/docs/dxml/0.3.2/dxml_parser.html#.parseXML
- Jonathan M Davis
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Monday, 21 May 2018 at 07:10:34 UTC, rikki cattermole wrote: alias DocumentType = SomeDocument!( ObjectVersion._1_0, ObjectEncoding.PlainASCII ); alias DocumentType2 = SomeDocument!( ObjectEncoding.UTF8, ObjectVersion._2_0 ); typedef basic_stringstring; typedef basic_string wstring; So, as I understand, basic idea can be reduced to "Let's use traits for options!", isn't it?
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Monday, 21 May 2018 at 14:36:32 UTC, Jacob Carlborg wrote:
enum Options options = { foo: true, bar: false, a: 42, b:
"guess what this does" };
SomeObject!options o;
--
/Jacob Carlborg
I like this especially if you mix it with:
enum Options options = { foo: true, bar: false, a: 42, b: "guess
what this does" };
SomeObject!options o;
class myClass(Options options)
{
void myFunction()
{
static if(options.foo)
{
... //some code
}
}
}
class MyOtherClass(Options options)
{
void myOtherFunction()
{
static if(options.foo && options.bar)
{
... //some code
}
}
}
All of a sudden you encaptulate your template arguments whitout a
lot of effort and allow them to be easily re-used, computed and
altered.
It becomes even more convenient if you're computing the content
of `Options` at compile time using some complicated statements.
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Monday, 21 May 2018 at 14:23:07 UTC, Steven Schveighoffer
wrote:
But how do you use it?
SomeObject!(Options(true, false, 42, "guess what this does"))
Yes, or if you want something more readable:
enum Options options = { foo: true, bar: false, a: 42, b: "guess
what this does" };
SomeObject!options o;
--
/Jacob Carlborg
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On 5/21/18 10:07 AM, Jacob Carlborg wrote:
On Monday, 21 May 2018 at 00:13:26 UTC, Ethan wrote:
Code for context:
https://github.com/GooberMan/binderoo/blob/master/binderoo_client/d/src/binderoo/util/enumoptions.d
Something struck me at DConf. I was watching the dxml talk and hearing
about all these things that weren't being implemented for one reason
or another. And I was thinking, "But what if I want those things?"
Being D, it'd be pretty easy to opt in to them with template
parameters and static if controlling what code gets executed at runtime.
But that brings up a bit of an annoying thing. Namely, the old school
way of doing such things:
class SomeObject( bool option1, bool option2, Flags iHateBools =
Flags.Default, int ohIDontWantThisToBeDefaultedButRefactoringSucks = -1 )
{
}
Pretty obnoxious design pattern.
But we're in D. We can do much better. It makes sense to do the
following:
class SomeObject( LooseOptions... )
{
}
Unless I'm missing something we can do a lot better in D :
struct Options
{
bool foo;
bool bar;
int a;
string b;
}
class SomeObject(Options options)
{
static if (options.foo)
{
}
}
No magic templates or anything fancy.
But how do you use it?
SomeObject!(Options(true, false, 42, "guess what this does"))
-Steve
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Monday, 21 May 2018 at 00:13:26 UTC, Ethan wrote:
Code for context:
https://github.com/GooberMan/binderoo/blob/master/binderoo_client/d/src/binderoo/util/enumoptions.d
Something struck me at DConf. I was watching the dxml talk and
hearing about all these things that weren't being implemented
for one reason or another. And I was thinking, "But what if I
want those things?" Being D, it'd be pretty easy to opt in to
them with template parameters and static if controlling what
code gets executed at runtime.
But that brings up a bit of an annoying thing. Namely, the old
school way of doing such things:
class SomeObject( bool option1, bool option2, Flags iHateBools
= Flags.Default, int
ohIDontWantThisToBeDefaultedButRefactoringSucks = -1 )
{
}
Pretty obnoxious design pattern.
But we're in D. We can do much better. It makes sense to do the
following:
class SomeObject( LooseOptions... )
{
}
Unless I'm missing something we can do a lot better in D :
struct Options
{
bool foo;
bool bar;
int a;
string b;
}
class SomeObject(Options options)
{
static if (options.foo)
{
}
}
No magic templates or anything fancy.
--
/Jacob Carlborg
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Monday, 21 May 2018 at 13:22:33 UTC, Steven Schveighoffer wrote: Filter was written before static foreach existed. This is a pretty low-hanging fruit if anyone wants to try it out. -Steve I've gone to the effort after all, I might as well just port my code across. I'll look in to it. Probably not this week though, off to Copenhagen/Malmö in a few hours.
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On 5/21/18 5:30 AM, Ethan wrote: On Monday, 21 May 2018 at 03:30:37 UTC, Paul Backus wrote: Am I missing something, or is this the same thing as `std.meta: Filter`? Nope, I am missing something. I don't find the std library documentation anywhere near as easy to look through as something like cppreference.com, so I only tend to go there when I know what I'm looking for. And in this case, I know the std.meta containers are implemented using recursive templates. Which is not particularly nice on the compiler. The difference with mine (apart from the name mismatch) is that I use string mixins and iterate over items in a for loop, which I've done with quite a few traits to try and get compile times a bit more reasonable on larger codebases. Filter was written before static foreach existed. This is a pretty low-hanging fruit if anyone wants to try it out. -Steve
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Monday, 21 May 2018 at 01:53:20 UTC, Manu wrote: I don't really like that SomeObject() will be instantiated a crap load of times for every possible combination and order of options that a user might want to supply. How do you control the bloat in a way that people won't mess up frequently? On Monday, 21 May 2018 at 00:58:10 UTC, Neia Neutuladh wrote: These are not the same type; they're two identical types with different mangles. Yep, entirely something I missed when I did the code. Classic "Works For Me!(TM)" moment. As mentioned by Neia, the thin wrapper would be my preferred way of approaching that, at which point your implementation class looks like: class Impl( alias Version, alias Encoding ) There's nothing stopping you doing the proposed std.meta.sort either, but that's essentially doubling up on work when you do something like what I illustrated.
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Monday, 21 May 2018 at 03:30:37 UTC, Paul Backus wrote: Am I missing something, or is this the same thing as `std.meta: Filter`? Nope, I am missing something. I don't find the std library documentation anywhere near as easy to look through as something like cppreference.com, so I only tend to go there when I know what I'm looking for. And in this case, I know the std.meta containers are implemented using recursive templates. Which is not particularly nice on the compiler. The difference with mine (apart from the name mismatch) is that I use string mixins and iterate over items in a for loop, which I've done with quite a few traits to try and get compile times a bit more reasonable on larger codebases. Otherwise, the usage technique is exactly the same.
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On 21/05/2018 12:13 PM, Ethan wrote:
Code for context:
https://github.com/GooberMan/binderoo/blob/master/binderoo_client/d/src/binderoo/util/enumoptions.d
Something struck me at DConf. I was watching the dxml talk and hearing
about all these things that weren't being implemented for one reason or
another. And I was thinking, "But what if I want those things?" Being D,
it'd be pretty easy to opt in to them with template parameters and
static if controlling what code gets executed at runtime.
But that brings up a bit of an annoying thing. Namely, the old school
way of doing such things:
class SomeObject( bool option1, bool option2, Flags iHateBools =
Flags.Default, int ohIDontWantThisToBeDefaultedButRefactoringSucks = -1 )
{
}
Pretty obnoxious design pattern.
But we're in D. We can do much better. It makes sense to do the following:
class SomeObject( LooseOptions... )
{
}
Much nicer. But how do we go about dealing with that? Static foreach
each time we want something? One time parse and cache the values? Both
are laborious in their own way. What we want is some helper objects to
make sense of it all.
This is where my EnumOptions struct comes in. The idea here is that all
the options you want as booleans, you put them in an enum like so:
enum SomeOptions
{
Option1,
Option2,
Option5,
Option3Sir,
Option3
}
And then instantiate your class like so:
alias SomeInstantiatedObject = SomeObject!( SomeOptions.Option1,
SomeOptions.Option2, SomeOptions.Option3 );
And inside your class definition, you clean it up automagically with a
nice little helper function I made:
class SomeObject( LooseOptions... )
{
enum Options = OptionsOf( SomeOptions, LooseOptions );
}
This resolves to an EnumOptions struct that parses all members of an
enumeration, and generates bits in a bitfield for them and wraps it all
up with properties. So now the following is possible:
static if( Options.Option1 )
{
// Do the slow thing that I would like supported
}
Now, if you've been able to keep up here, you might have noticed
something. Your class has a variable template parameter list. Which
means we can throw anything in there. The plot thickens. This means you
can go one step further and make your options actually human readable:
enum ObjectVersion
{
_1_0,
_1_1,
_2_0,
}
enum ObjectEncoding
{
UTF8,
UTF16,
UTF32,
PlainASCII,
ExtendedASCII,
}
class SomeDocument( Options... )
{
enum Version = OptionsOf( ObjectVersion, Options );
enum Encoding = OptionsOf( ObjectVersion, Options );
}
alias DocumentType = SomeDocument!( ObjectVersion._1_0,
ObjectEncoding.PlainASCII );
alias DocumentType2 = SomeDocument!( ObjectEncoding.UTF8,
ObjectVersion._2_0 );
Pretty, pretty, pretty good.
With this in the back of my mind, I've been able to expand Binderoo's
module binding to be a bit more user friendly. I've got a new
BindModules mixin, which unlike the existing mixins are more of a
pull-in system rather than a push-in system. Basically, rather than
BindModule at the bottom of each module, you put a single BindModules at
the bottom of one module and list every module you want as a parameter
to it.
The mixin needs to do a few things though. The list of modules is one
thing. A bunch of behaviour options is another. And, since the mixin
adds a static shared this, a list of functions that need to be executed
for module initialisation. The first two are pretty easy to deal with:
enum Modules = ExtractAllOf!( string, Options );
enum BindOptions = OptionsOf!( BindOption, Options );
But the functions, they're a bit trickier. So I made a new trait in
Binderoo's traits module called ExtractTupleOf. The template prototype
is the following:
template ExtractTupleOf( alias TestTemplate, Symbols... )
That first parameter is the interesting one. It's essentially an
uninstantiated template that doubles as a lambda. The template is
expected to be an eponymous template aliasing to a boolean value, and
take one parameter (although, theoretically, a CTFE bool function(T)()
would also work). ExtractTupleOf will static foreach over each symbol in
Symbols, and static if( TestTemplate!Symbol ) each one. If it returns
true, then that symbol is extracted and put in a new tuple.
What does this mean? It means I can do this:
import std.traits : isSomeFunction;
mixin BindModuleStaticSetup!( ExtractTupleOf!( isSomeFunction, Options ) );
All of this is very definitely well in the real of "Let's see you do
that in the hour it took me to throw it all together, C++!" territory.
And I'd really like to see people pick up this pattern rather than
emulate the old ways.
Another option[0] ;)
[0] https://github.com/rikkimax/DIPs/blob/named_args/DIPs/DIP1xxx-RC.md
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Monday, 21 May 2018 at 01:53:20 UTC, Manu wrote: I don't really like that SomeObject() will be instantiated a crap load of times for every possible combination and order of options that a user might want to supply. How do you control the bloat in a way that people won't mess up frequently? Just sort types by .stringof in a thin forwarding template, we have sort in std.meta now. On 20 May 2018 at 17:58, Neia Neutuladh via Digitalmars-d wrote: [...]
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Monday, 21 May 2018 at 00:13:26 UTC, Ethan wrote: But the functions, they're a bit trickier. So I made a new trait in Binderoo's traits module called ExtractTupleOf. The template prototype is the following: template ExtractTupleOf( alias TestTemplate, Symbols... ) That first parameter is the interesting one. It's essentially an uninstantiated template that doubles as a lambda. The template is expected to be an eponymous template aliasing to a boolean value, and take one parameter (although, theoretically, a CTFE bool function(T)() would also work). ExtractTupleOf will static foreach over each symbol in Symbols, and static if( TestTemplate!Symbol ) each one. If it returns true, then that symbol is extracted and put in a new tuple. Am I missing something, or is this the same thing as `std.meta: Filter`?
Re: A pattern I'd like to see more of - Parsing template parameter tuples
I don't really like that SomeObject() will be instantiated a crap load
of times for every possible combination and order of options that a
user might want to supply. How do you control the bloat in a way that
people won't mess up frequently?
On 20 May 2018 at 17:58, Neia Neutuladh via Digitalmars-d
wrote:
> On Monday, 21 May 2018 at 00:13:26 UTC, Ethan wrote:
>>
>> Code for context:
>> https://github.com/GooberMan/binderoo/blob/master/binderoo_client/d/src/binderoo/util/enumoptions.d
>
>
> This looks good. One small caveat:
>
> alias DocumentType = SomeDocument!(ObjectVersion._1_0, ObjectEncoding.UTF8);
> alias DocumentType2 = SomeDocument!(ObjectEncoding.UTF8,
> ObjectVersion._1_0);
>
> These are not the same type; they're two identical types with different
> mangles. You can fix that with a layer of indirection:
>
> template SomeDocument(Options...)
> {
> alias SomeDocument = SomeDocumentImpl!(OptionsOf!(DocumentParams,
> Options));
> }
Re: A pattern I'd like to see more of - Parsing template parameter tuples
On Monday, 21 May 2018 at 00:13:26 UTC, Ethan wrote:
Code for context:
https://github.com/GooberMan/binderoo/blob/master/binderoo_client/d/src/binderoo/util/enumoptions.d
This looks good. One small caveat:
alias DocumentType = SomeDocument!(ObjectVersion._1_0,
ObjectEncoding.UTF8);
alias DocumentType2 = SomeDocument!(ObjectEncoding.UTF8,
ObjectVersion._1_0);
These are not the same type; they're two identical types with
different mangles. You can fix that with a layer of indirection:
template SomeDocument(Options...)
{
alias SomeDocument =
SomeDocumentImpl!(OptionsOf!(DocumentParams, Options));
}
