Approach to the implementation of tuple in. NET 2.0

When I introduced Visual Basic 9.0, I mentioned the concept of tuple many times as an instance of an anonymous type. Now we are going to discuss this concept alone. Tuple is often translated as "tuple", and in most languages that support it, it often means that the number of members is determined and the structure of each member type is determined. Often used to represent multiple return values of a function, or the results of a query. Tuple should be strongly typed, that is, the type of all members is determined at compile time. For example, under the hypothetical syntax

Dim t = New Tuple (of String, Integer, Double)

Then T will have three members, the number cannot be changed, and the three member types are string, Integer, and double, and cannot be changed. As you can see, tuple may be seen as a structure without prior declaration, which can be created flexibly according to the situation used. The anonymous types of VB9 and c#3 are, of course, tuple good implementations. But this is the N-year thing, can we implement tuple in. NET 2.0? The key difficulty is that we have to create a tuple structure where we want to use it, rather than declaring it beforehand, so we have to have a flexible mechanism to do it.

Method One: Typelist

I was thinking about this on the bus one day, and then I saw the similarities with the Loki typelist. Of course. NET does not have the ability to be special and record type, so it cannot implement Typelist. But we move the static type operation idea to run, can do typed Variable list--that is tuple.

Public abstract class Typenode {internal Typenode {}}

public sealed class Tail:typenode {}

Public sealed class Tuple<t, tnode>: Typenode where Tnode:typenode, new ()
{
Public T Field = default (t);
Public Tnode Next = new Tnode ();
}

I took full advantage of it. NET generic constraints to achieve my design. Typenode is designed as abstract, so the generic parameter tnode that constrains the new () will not be able to take the type of the value Typenode itself. The internal constructor also restricts the user from inheriting it. This method limits the range of Tnode to the two types of tail and tuple. This usage is quite ingenious in my opinion of constraint usage.

The principle of this type is simply to use generics to automatically generate a linked list of the same structure when creating an instance of Typelist. For example, we're going to create a string, Integer, double tuple, and that's what it says:

Tuple<string, Tuple<int, tuple<double, tail>>> t;

As you can see, the type parameter of this tuple is the type of a node, the second is either another tuple, or tail (represents the end list). After this object is created, a list of "different node types" is automatically generated.

t = new tuple<string, Tuple<int, Tuple<double, tail>>> ();
T.field = "a string";
T.next.field = 123;
T.next.next.field = 13.56;

Tail does not have a next field, so encountering tail represents the end of tuple, which can be checked by the compiler, so there is no danger of crossing over. And this kind of tuple can reach infinitely long. However, this method is also flawed, the first use of the grammar is very inconvenient, if you want to use the 7th field, to write MyTuple.Next.Next.Next.Next.Next.Next.Field, a little attention will be written wrong. Both VB and C # do not have enough abstraction to simplify this operation. The second flaw is that a series of new operations are expensive when creating tuple, because the new here is done by reflection. So limited by the lack of language characteristics, this method can not achieve a perfect point, but this idea may be used in other situations.

Method Two: Overloaded prototype

To emulate the idea of a generic delegate, we can simulate the tuple created with a completely generic series of identically named structures:

struct tuple<t0>
{
Public T0 Field0;
}

struct Tuple<t0, t1>
{
Public T0 Field0;
Public T1 Field1;
}

struct tuple<t0, T1, t2>
{
Public T0 Field0;
Public T1 Field1;
Public T2 Field2;
}
......
struct tuple<t0, T1, T2, T3, T4, T5, T6, T7, T8, t9> {...}

This creates a set of tuple structures. Because the name is the same, there are 10 types that are not detected in use, but "what to have":

tuple<string, int, double> t1;
Tuple<string, string> T2;
tuple<int, int, int, int, float> T3;
......

It's the same syntax we started with! And without any extra overhead, it's pretty perfect. But it has a limited number of elements, the first definition of a few can only have a few, fortunately, generally do not need too much, 10 enough. However, this generated tuple a bit rigid, there seems to be no intelligent place.

I will use the second tuple scheme in my vbf, and I think it is more practical. The only place to change is to add a constructor for each tuple structure that initializes all the members.