digitalmars.D.learn - Small code review
- mist (8/8) Jun 18 2012 Subj: http://dpaste.dzfl.pl/dfab7219
- Jonathan M Davis (22/30) Jun 18 2012 Stylistically-speaking, template parameters should follow the same
- mist (12/30) Jun 20 2012 Could you add more details here?
- Jonathan M Davis (18/31) Jun 20 2012 std.typelist is basically just forgotten cruft sitting in Phobos. It was...
Subj: http://dpaste.dzfl.pl/dfab7219 I wanted to code a small extension to phobos typetuple module to extend basic available operations on type tuples more on par with std.algorithm ones. I don't have enough practice in metaprogramming "D way" though and would gladly listen any recommendations in both improving code style and possible ways to implement similar things in shorter and more canonical way. Thanks!
Jun 18 2012
On Monday, June 18, 2012 23:41:01 mist wrote:Subj: http://dpaste.dzfl.pl/dfab7219 I wanted to code a small extension to phobos typetuple module to extend basic available operations on type tuples more on par with std.algorithm ones. I don't have enough practice in metaprogramming "D way" though and would gladly listen any recommendations in both improving code style and possible ways to implement similar things in shorter and more canonical way.Stylistically-speaking, template parameters should follow the same capatilization rules as everything else. If they represent types, then they should be PascalCase. Everything else is camelCased. And in the cases where it's not known (as might be the case with an alias), camelCasing is used. Also, if an eponymous template is going to resolve to a type it should be PascalCased, and if it's going to resolve to something else, it should be camelCased. As for what your stuff is doing, I don't see anything blatantly wrong with it, but I question the wisdom of hoving filterNum be part of filter. It _is_ doing something similar to filter, but it's distinctly different. You might want to take a look at std.typelist: https://github.com/D-Programming-Language/phobos/blob/master/std/typelist.d It's a rather old module which is not actually included in the Phobos build right now (I guess that it never quite made it in, and I'm not quite sure what we're going to do with it). It probably does some of the sort of stuff that you're looking for, though it takes a very different approach. If it were to be fully included as part of Phobos, it would need some updating (e.g. fixing how it names its symbols, since it doesn't always follow Phobos' naming conventions correctly), but it's probably worth your time to look at it if you're really looking to manipulate TypeTuples with algorithms. - Jonathan M Davis
Jun 18 2012
Could you add more details here? What is current official position? Updating typelist.d and merging with typetuple.d? Keeping current one and rewriting some algorithms from typelist to work with current TypeTuple? My point is exactly that it is not that much important how such library looks like, but it is only good if included in std lib. Too minor to keep as separate library, too generic to copy-paste needed in every project required. It is best to just "have it here" when you notice that some neat tuple trick can beautify this minor part of your code. I'd gladly to do any stuff that needs to be done to include this functionality in Phobos. What are my best options?You might want to take a look at std.typelist: https://github.com/D-Programming-Language/phobos/blob/master/std/typelist.d It's a rather old module which is not actually included in the Phobos build right now (I guess that it never quite made it in, and I'm not quite sure what we're going to do with it). It probably does some of the sort of stuff that you're looking for, though it takes a very different approach. If it were to be fully included as part of Phobos, it would need some updating (e.g. fixing how it names its symbols, since it doesn't always follow Phobos' naming conventions correctly), but it's probably worth your time to look at it if you're really looking to manipulate TypeTuples with algorithms. - Jonathan M Davis
Jun 20 2012
On Wednesday, June 20, 2012 18:59:08 mist wrote:Could you add more details here? What is current official position? Updating typelist.d and merging with typetuple.d? Keeping current one and rewriting some algorithms from typelist to work with current TypeTuple? My point is exactly that it is not that much important how such library looks like, but it is only good if included in std lib. Too minor to keep as separate library, too generic to copy-paste needed in every project required. It is best to just "have it here" when you notice that some neat tuple trick can beautify this minor part of your code. I'd gladly to do any stuff that needs to be done to include this functionality in Phobos. What are my best options?std.typelist is basically just forgotten cruft sitting in Phobos. It wasn't fully integrated, and I don't know how complete it really is. The file is sitting there, but that's about it. I think that we'd all forgotten about its existence until someone noticed it and brought it up in the Phobos newsgroup the other day. It's a cool idea, but it would probably need to be discussed in the main newsgroup before we did anything with it. It's one of those things that was done earlier in D's development when Phobos' situation was less organized. As for your options for submitting stuff to Phobos (in general, not necessarily specific to this issue), if it's small stuff, then you can simply create pull requests on github ( https://github.com/D-Programming-Language/phobos ), and Phobos devs will look it over and possibly merge it. But if it's larger stuff (especially if it involves adding a new module), then it needs to go through the official review process, where it's reviewed and voted on in the main newsgroup before it can be included in Phobos (std.uuid is going through that process right now). - Jonathan M Davis
Jun 20 2012