Difference between revisions of "Instantiator Function Pattern"

From D Wiki
Jump to: navigation, search
(Created article)
 
m
 
Line 38: Line 38:
  
 
The instantiator function takes a variadic set of arguments and instantiates <code>Tuple</code> based on those arguments.  In D, the return type can be introspected so the return type doesn't need to redundantly specified. In <code>main</code>, redundantly specifying argument types that the compiler already knows is avoided.
 
The instantiator function takes a variadic set of arguments and instantiates <code>Tuple</code> based on those arguments.  In D, the return type can be introspected so the return type doesn't need to redundantly specified. In <code>main</code>, redundantly specifying argument types that the compiler already knows is avoided.
 +
 +
[[Category:DesignPattern]]

Latest revision as of 10:18, 14 November 2014

From David Simcha's D-Specific Design Patterns talk at DConf 2013.

Problem: Instantiating class/struct templates

struct Tuple(Args...)
{
    Args args_;
}

void main()
{
    //Yuck!
    auto myTuple = Tuple!(int, double, string)(1, 3.14, "foo");
}

The compiler already knows that 1 is an int, 3.14 is a float and "foo" is a string, yet this information is specified redundantly. To change one of the arguments, it must be changed in two different places.

Solution: Use Instantiator Function

struct Tuple(Args...)
{
    Args args_;
}

// Instantiator function
Tuple!(Args) tuple(Args...)(Args args)
{
    return typeof(return)(args);
}

void main()
{
    // Much less verbose.  Use IFTI.
    auto myTuple = tuple(1, 3.14, "foo");
}

The instantiator function takes a variadic set of arguments and instantiates Tuple based on those arguments. In D, the return type can be introspected so the return type doesn't need to redundantly specified. In main, redundantly specifying argument types that the compiler already knows is avoided.