Concepts where an object can behave like it implements an interface which it has the method signatures for, w/o explicitly implementing the interface?

Question

I'd like to ask whether this is a useful concept, if other languages have ever done this sort of thing, or if this idea is problematic or just bad. If it is problematic, an explanation of what principles it violates would also be greatly appreciated.

For the sake of being clear about what I mean, I've written some C# pseudocode where I've created an imaginary "lazy" keyword that provides a concrete implementation of this idea. The "lazy" keyword instructs the compiler to 1) explicit cast any object that has functions that conform to an interface contract to that interface, even if the object in question does not explicitly implement the interface and 2) if said explicit cast function doesn't exist, create it, 3.) The object can be cast back to what it was originally, 4.) If the object doesn't implement the methods required by the interface, you get a compiler error.

Then the following code would compile and run.

class Program
{
    public interface iRoll
    {
        public void Roll();
        public int Dimensions { get; set;}
    }

    public class Basketball
    {
        public void Roll()
        {
            Console.WriteLine("I'm a rolling basketball");
        }
        private int _dimensions = 3;
        public int Dimensions { get { return _dimensions; } set { _dimensions = value; } }
        public string Brand = "BallCo.";
    }

    public class Tire
    {
        public void Roll()
        {
            Console.WriteLine("I'm a rolling tire");
        }
        private int _dimensions = 3;
        public int Dimensions { get { return _dimensions; } set { _dimensions = value; } }
    }

    static void Main(string[] args)
    {
        Tire MyTire = new Tire();
        Basketball MyBall = new Basketball();
        var myList = new List<iRoll>();
        myList.Add(lazy iRoll MyTire);
        myList.Add(lazy iRoll MyBall);
        foreach(iRoll myIRoll in myList)
        {
            myIRoll.Roll();
            Console.WriteLine("My dimensions: " + myIRoll.Dimensions);
        }
    }
}

The benefits are not always having classes implement interfaces like crazy, and not having to derive from a base class just to implement a custom interface when the base class already has the methods and properties you need (e.g., certain situations with external libraries, certain UI controls).

Good idea, bad idea, terrible idea? Do any other languages experiment with this?

Look into "structural typing" (http://en.wikipedia.org/wiki/Structural_type_system) as used, for example, in Go. — Jacob Mattison, May 15 '14 at 20:31
Sounds like you're describing [structural typing](http://en.wikipedia.org/wiki/Structural_typing). — Oliver Charlesworth, May 15 '14 at 20:31
This pretty much exactly describes how Groovy handles interfaces if I'm not mistaken--Except groovy uses less explicit mechanisms, any cast explicit or implicit acts like your "Lazy" keyword. In fact they have a similar syntax for it, you would say "MyTire as iRoll" instead of lazy iRoll MyTire. — Bill K, May 15 '14 at 20:33
I kind of like the idea of having a keyword that lets you do this only when you specifically want to, although I don't think "lazy" is necessarily the right word (given the association with lazy loading). Maybe something like "coerce"? — Jacob Mattison, May 15 '14 at 20:34
(And if I needed to implement this I think I'd wrap the item in a dynamic proxy that implemented the interface and handed the method call off to the actual object.) — Jacob Mattison, May 15 '14 at 20:35
This does sound like structural typing from what I can tell at a glance, thank you - I will read more about that. "lazy" would be a terrible keyword name, I think. I just picked it because I'm being... ahem. ;) — John, May 15 '14 at 20:37
Also known as [Duck Typing](http://en.wikipedia.org/wiki/Duck_typing) — Bobson, May 15 '14 at 21:12
The quite successful [Go](http://golang.org) programming language is centered around this concept: to satisfy an interface, the type of a value only has to implement the set of methods required by that interface. See [this](http://research.swtch.com/interfaces) for details. — kostix, May 16 '14 at 12:56

score 0 · Answer 1 · edited May 23 '17 at 10:32

Thanks to all of you for the information. I found a similar question to my own with some interesting information. Two very important related and different concepts to learn about are structural typing and duck typing , both of which could fit my original question.

In my example, C# uses nominal typing which is not compatible with structural typing. The "lazy" keyword I proposed is a keyword that causes a nonimally-typed system to do certain things that make it look to a programmer like a structurally typed system. That should be static duck typing in a nominally typed language, for this example.

I wonder if someone could say the lazy keyword isn't "really" duck typing, but semantic sugar to have classes implement interfaces, if the implementation details of the lazy keyword caused the compiler to have the class operated on to implement any interfaces it needs to implement at compile time. However, I think duck typing is an OOP concept, so this should be duck typing regardless of what the compiler does as long as the end result acts like duck typing. Please feel free to correct anything I'm mistaken about or disagree.

There's a great section in the Wikipedia article about duck typing that shows many examples of it in programming languages.

Concepts where an object can behave like it implements an interface which it has the method signatures for, w/o explicitly implementing the interface?

1 Answers1