Is structural typing in a hierarchical model necessary?

Question

This is part of a series of questions which focuses on a project called the Abstraction Project, which aims to abstract the concepts used in language design in the form of a framework.

Another page associated to it related to ease of use can be viewed here. The meta-topic associated to an inquiry about the framework and the proper place to post can be found here.

I'm writing a framework which describes the concepts within static high-level languages (like C#, VB.NET, et cetera). As a part of that, it involves synthesis of the structures that describe those concepts.

One question I had was about what's called Structural Typing, which I aim to implement through type-parameters (constructors with parameters would be a definite addition.) It's a concept that neither C# nor VB.NET implement.

The question I have today is: is structural typing in a hierarchical model necessary?

One small example that I can think of is models developed that rely on patterns, but don't necessarily have an interface to specify this pattern. This is useful in instances where you want to use the code for multiple base types without a common ancestor, but with similar structure.

If you wanted to display a list of items to the Console via their name, you'd need to write one method for the lowest common ancestor that defines that name property. Person, Control, and Type would all use different methods, as an example.

If implemented, the resulted code would look something like:

public static void DisplayNames<T>(IEnumerable<T> namedItems)
    where T has
    {
        ///<summary>Returns the item's name</summary>
        string Name { get; }
    }
{
    foreach (var namedItem in namedItems)
        Console.WriteLine(namedItem.Name);
}

The '[' and ']' are used for disambiguation reasons (it'd be difficult to try to discern the body of a type-parameter's structure from an interface's structure otherwise.)

Suggestions welcome.

Answer 1

It looks like you are trying to combine compile-time safety with duck-typing.

C++ templates already do this automatically - you can attempt to call anything on a template's parametrized type and it will fail to compile if the template type does not support that call. Things are kept generic by another template feature: if you do not use a specific feature of a specific template instantiation (implying a specific parametrized type), then it doesn't matter that a definition exists which does not compile. If you don't use it, it's not an error. Example:

class MyClass 
  {
  public:
     MyClass() {}
     std::string GetName() const { return "MyClass"; }
  };

template<typename T>
class TMyTemplate
  {
  public:
    TMyTemplate()
      {
      std::cout << myClassInstance_.GetName();
      }

    void ConceptMemberFunction()
      {
      std::cout << myClassInstance_.ConceptFunction()
      }

  private:
    T myClassInstance_;
  };


  int main(void)
    {
    TMyTemplate<MyClass>  myTemplate; // Compiles just fine.
    // myTemplate.ConceptMemberFunction(); // Compile-time error
    }

This feature of templates can be used for compile-time "concept checking" (see boost::concept_check) - create and instantiate a template that "uses" the specific features that the concept requires - compilation will fail if the class does not support all the required features.

Are these the concepts you are referring to in your question?

Answer 2

Given that most of the above answers essentially provided more context as to the nature of what structural typing is, not so much focused on whether it was necessary, as the initial question stated. I will mark this answer as implicit and based upon the target audience of the language.

For certain programming patterns a structural typing model on top of a static typing model is warranted; however, at the same time the specific implementation or current implementations don't add relevant context to the question at hand as they are examples of it in use. They explicitly state it is possible, but don't relate how it being possible relates to the need aspect initially requested in the original question.

Thus we'll answer the question by the following: it's needed where appropriate in a development environment that provides explicit type-based implementation constraints as well as an environment where two separately developed libraries follow the same pattern but do not share a common ancestor or implement the same interfaces, this is where structural typing would come into play.

Use cases are easier to come up with given a language that promotes both kinds of typing as noted by @back2dos, but that in and of itself does not answer the need aspect, it answers the question of whether it can be done.

Answer 3

Well, it can be combined. Specifically haXe shows this.

This has some advantages:

• It lowers coupling. The target of an abstraction doesn't need to know it is being abstracted. (Granted, you could use adapters, but in most languages, that's a lot of work).
• It allows abstracting over class objects. In haXe you could do something as:
  typedef Singleton<T> = { function getInstance():T }, which allows abstracting over all classes (or instances or anonymous objects) that match this type.

It has some disadvantages:

• It is quite hard to implement in a fast way (compared to interfaces). When compiled to static languages, haXe uses reflection to operate on such types, which is quite costly.
• It is a relatively weak contract. I.e.: Is it legitimate to interpret everything, that has a float x and y property as a point? Proponents of duck-typing probably answer with a firm yes. I am not so sure.

One thing you should see is that function types are in fact a special kind of structural types, which allow abstraction over function values.

Interfaces do have advantages over structural types. An interface does not only describe a structure. It describes a role. When a class chooses to implement an interface, it means, it is suitable to play such a role. There is a sort of reliability to that, that structural types cannot give you. Just because something can quack, it isn't necessarily suitable to be used as a duck.
For function types, this becomes quite evident. If you take SomeType->Bool as a function type, this doesn't describe the role of the function. The function could be performing an operation (such as removing an item from a collection) and saying, whether it failed or not, but it could also be a test to be performed on an object, that can either pass or fail.

You could say structural subtyping is a good tool to maintain type safety in abstractions that elude all other type semantics provided by a language. It is a powerful tool, that should be used with care.