Can we have implicitly typed members?

Question

Implicit typing in languages like C# permits compile-time type checks without necessarily referring "directly" to a target class:

var toy = SantasWorkshop.Build();
toy.amuse();

In this scenario, we don't need to know what type of toy it is. And yet, we'll still know at compile-time whether our toy fails to amuse().

However, this is limited to the local scope. If we want to put that toy into a Stocking and retain the compile-time checks, we need to know something about it at compile time -- other than it's ability to amuse(). E.g., this is illegal:

class Stocking {
  List<var> toys;
  public void add(var toy) {
    toys.add(toy);
  }
}

If we're willing to sacrifice on the compile-time check, languages like C# allow us to use dynamic typing:

class QuestionableLookingStocking {
  List<dynamic> toysIHope;
  public void add(dynamic toyIHope) {
    toysIHope.add(toyIHope);
  }
}

But, this will allow us to add objects to a QuestionableLookingStocking that may not actually amuse(). And we won't know about it until someone adds Coal at runtime.

class Coal {
  public ChristmasMood ruinChristmas() {
    return new SadChristmas();
  }
}

Would it be logically possible and feasible for implicit typing to be extended to members? I.e., is there any reason the compiler couldn't complain if someone tries to Stocking.add() an object that doesn't support the operations required by all references to Stocking.toys[n]?

Are there patterns that could simulate implicit member types?

Answer 1

You can simulate all of this in C# using generics.

This code is legal:

class Stocking<T> {
  List<T> toys;
  public void add(T toy) {
    toys.add(toy);
  }
}

And I'm pretty sure it fulfills all of your established objectives: you get compile-time type safety over all of your members, and every toy is an object that supports the operations required by all references to Stocking.toys.

Naturally, you're not going to get any additional capabilities from each toy beyond what is already provided by type T, which is probably what you're really after. So how about trying something like this:

public class Toy
{
    public string Name { get; set; }
}

public class Truck: Toy
{
    public void Dump()
    {
        Console.WriteLine("Dumping");
    }
}

public class Stocking<T>
{
    List<T> toys = new List<T>();
    public void Add(T toy)
    {
        toys.Add(toy);
    }
    public T Get(int index)
    {
        return toys[index];
    }
}

public class Program
{
    public static void Main(string[] args)
    {
        var s = new Stocking<Toy>();
        var t = new Truck() { Name = "Tonka" };

        s.Add(t);
        var toy = s.Get(0);

        // Generic Toy behavior
        Console.WriteLine(toy.Name);

        // Truck-specific behavior
        if (toy is Truck)
        {
            (toy as Truck).Dump();
        }
        Console.ReadLine();
    }
}

This code outputs

Tonka
Dumping

Which is exactly what you would expect.

Answer 2

To expand upon Robert Harvey's answer:

You don't need to stop at Toy.

public class Possession
{
    public String Name {get; set;}

    public abstract void Use();
}

public class Toy : Possession
{
    public void Amuse()
    {
        Use();
    }
}

public class Truck : Toy
{
}

public class Dumptruck : Truck
{
    public override void Use()
    {
        Console.WriteLine("Dumping");
    }
}

public class Child
{
    public String Name {get; set;}
    public List<Possession> Owns;
    public List<Toy> Stocking;

    public void AddToStocking(Possession Item)
    {
        if (Item is Toy)
            Stocking.Add(Item);
        else
            throw new GrinchException($"{Item.Name} is not a toy, why are you trying to put it in {Name}'s stocking?");
    }
}