Back at dconf 2015, Andrei introduced design-by-introspection in his talk "Generic programing must go", he showed that not only classes have "class explosion" problems but so do templates.
The basic idea behind design by introspection the way I understand it is similar to the one  behind design patterns. One of the Gang of Four' two principles is "Favor object composition over class inheritance." i.e. inheritance must go, as Andrei would say.

Then I stumbled upon DIP84, which reminded me of the other GoF' principle "Program to an interface, not an implementation".
And I started wondering why would I ever write code like this:

    auto someAlgorithm(SomeInterface obj) { /* ... */ }

When I can do this:

    auto someAlgorithm(I)(I obj) if(isSomeInterface!I) { /* ... /* }

or more generically:

    auto someAlgorithm(I)(I obj)
    if(satisfiesInterface!(I, SomeInterface, SomeOtherInterface /*... etc */)
    { /* body ... /* }

This would be a modern design to introspection? that goes with the modern design by introspection.
While this approach has more code over the classic one, It has the advantage of working "natively" for both classes and structs (without dirty tricks like std.experimental.typecons.wrap does for structs), and would in the end save you a lot of code duplication, chaos and death if used along with design-by-introspection.

What do you think.

Am Fri, 07 Apr 2017 11:51:10 +0000
schrieb سليمان السهمي (Soulaïman Sahmi)
<sahmi.soulaimane@gmail.com>:

> […]
> 
> Then I stumbled upon DIP84, which reminded me of the other GoF' principle "Program to an interface, not an implementation". And I started wondering why would I ever write code like this:
> 
>      auto someAlgorithm(SomeInterface obj) { /* ... */ }
> 
> When I can do this:
> 
>      auto someAlgorithm(I)(I obj) if(isSomeInterface!I) { /* ...
> /* }
> 
> or more generically:
> 
>      auto someAlgorithm(I)(I obj)
>      if(satisfiesInterface!(I, SomeInterface, SomeOtherInterface
> /*... etc */)
>      { /* body ... /* }
> 
> This would be a modern design to introspection? that goes with
> the modern design by introspection.
> […]
> 
> What do you think.

Running the same algorithm on class and struct instances is a
much desired feature, especially where programmers tend to
fall into two camps where one mostly uses classes and the
other mostly uses structs.
But reasons for using one over the other slip into the concept
of one-function-to-rule-them-all as well. And there is more to
consider:

- Interfaces variables hold references to the data, while for
  structs you have to explicitly add "ref" to the argument or
  else the algorithm will work on a (shallow) copy.
- Wrapping structs in interfaces and using interfaces
  exclusively results in only on instance of the algorithm
  ending up in the executable instead of one per each class
  and struct type, which helps with things like executable
  size, instruction cache hits and debug symbol size and
  readability.
- Some forms of licensing break when using templates in the
  public API of libraries. Two examples:
  A proprietary software company sells programming libraries.
  They need to keep their source code private to prevent theft,
  but if their API used templates they'd have to provide
  sources for them and any templates used inside of them.
  On the other hand a GPL licensed open source library - to be
  usable in a proprietary project - must ensure that none of
  its code gets compiled into the target application. Again
  templates would break that.

Then there are other general considerations in favor of interfaces or templates.

- Template methods are not virtual functions that you can
  override in a child class.
- Calling virtual methods on interfaces is slower (on some
  architectures more than others)[1] and there is no static
  introspection to decide some code paths at compile time.
  (Devirtualization is a hot topic.)
- Templates increase complexity for the compiler and runtime.
  There have been a few subtle issues in the past, for example
  symbol name length explosion[2] and object files containing
  old code in separate compilation scenarios[3].

[1] http://eli.thegreenplace.net/2013/12/05/the-cost-of-dynamic-virtual-calls-vs-static-crtp-dispatch-in-c
[2] http://forum.dlang.org/post/efissyhagontcungoqkx@forum.dlang.org
[3] https://issues.dlang.org/show_bug.cgi?id=9922

-- 
Marco

On Friday, 7 April 2017 at 13:30:00 UTC, Marco Leise wrote:
> [...]
>

Thank you Marco, you have summarized the issues of both worlds.

I guess that's why java' implementation is different, templates in java are synonymous to classes. But that relies on virtualization, and is too restrictive, no primitive types allowed, no structs (java has no structs), and no structural subtyping (the object has to implement the interface).

Still I think there has to be a better way to implement templates.
as far as speed goes the current implementation is hard to beat, since every thing is flat, there's no overhead.

To add to the current implementations I think one way to implement templates or more generally structural subtyping (aka duck typing) would be, to pass metadata (offsets of functions and fields) to functions, the same way you would pass function arguments i.e in a defined order and signature. Every function would declare the metadata it requires for each argument passed i.e which field and function it uses on that object, i.e there's an extra signature (the compiler could take care of that).

Pros:
- static duck-typing (awesome).
- enables binary distribution since one instance suffices.
- faster than virtualization, it has less overhead with always only one indirection, to call a function fetch it from the argument list then call it.
- replaces virtualization, inheritance could be implemented on top of this.
- does not change the syntax of the language, only the compiler needs to worry about the extra signature introduced therefore it can be distributed as header files generated by the compiler.

Cons:
- introduces a extra signature.
- slower than the current implementation of templates, there is still an indirection (a pointer dereference is not an immediate value).
- the extra signature requires extra effort to keep ABI compatibility, which is an undesirable side effect, if the implementation of an algorithm changes it can't use different fields or functions without breaking the ABI.
- uses more space on the stack and cpu cache.
- more work for the compiler to infer the used fields and fuctions
- has some issues

Issues:
- static method calls and normal method calls are ambigious i.e functions and delegates.
- to add to that even fields get into the mess, in `a.b`, b could be a field or a method or a static field or a static method.
- conditional compilation notably used in design by introspection can't be worked at runtime. but since conditional compilation is predictable unlike generic programing, maybe all possible branches could be compiled into the binary and the compiler could just link to one of them.

This is just one other way to consider maybe there more, there always is, we just need to think outside the box (sometimes recursively).