Return to Answer

added 33 characters in body

Source Link

edited Jul 22, 2020 at 10:42

Christophe

80.6k
11
132
199

It's always possible

There are already lots of work-arounds to implement multi-methods in languages that don't support itthem:

Some use dispatch tables. The most impressing is imho in Alexandrescu's Modern C++ Design where template magic is used to make it happen almost naturally... provided that you're very versed in template programming.
Some hijack the build-in single dispatch to make a double-dispatch happen. All you need is a "bounce-back call""bounce-back call" in which each class has the responsibility of performing one level of dispatching. Google for double-dispatch in your favourite language and you'll get it.

Since there are known solutions to implement it, it can for sure be automated and build into the language.

It's just matter of cost and sacrifice

Performance: the more dimensions in the dispatch, the slower will the dispatch be. It's either because of more indirections or because of complexer searches in larger dispatch tables.
Design: this design is not in the mind of the Open/Close principle since you'd need to add a new implementation when a new partner-class is derived: you have to know in advance the possible interactions.

The design sacrifice of both the Open/Close principle, but also the principle of least knowledge is in my view the main reason why there are not much languages that offer what you expect.

Your example

Take the example of your overlap() and imagine there would be a way to add multi-methods (i.e. methods in the class and not free-standaing functions):

Imagine that you have implemented the Shape Circle Triangle and Retangle.
Imagine even that you've found a nice trick to take advandage of the symetry of the problem.
Your classes are fine and delivered in a library. Now the user of your library adds a new Shape, for example Octopus: how would this interact with your library: the user will not be able to change your library (close) - how can he/she extend it?

Conclusion : the solution should remain outside of the class

In your example, finding the overlap is in fact not the concern of one single class, but of two classes together. Adding a new class that intervenes in this dynamic, requires to define new couples of possible interactions. So in the end the interaction belongs not to the class, but to the context that knows about the potential classes in presence.

And if you consider the problem under this angle, the existing solution already offered for multiple-dipatch in C# seems to be the most promising to go.

It's always possible

There are already lots of work-arounds to implement multi-methods in languages that don't support it:

Some use dispatch tables. The most impressing is imho in Alexandrescu's Modern C++ Design where template magic is used to make it happen almost naturally... provided that you're very versed in template programming.
Some hijack the build-in single dispatch to make a double-dispatch happen. All you need is a "bounce-back call" in which each class has the responsibility of performing one level of dispatching. Google for double-dispatch in your favourite language and you'll get it.

Since there are known solutions to implement it, it can for sure be automated and build into the language.

It's just matter of cost and sacrifice

Performance: the more dimensions in the dispatch, the slower will the dispatch be. It's either because of more indirections or because of complexer searches in larger dispatch tables.
Design: this design is not in the mind of the Open/Close principle since you'd need to add a new implementation when a new partner-class is derived: you have to know in advance the possible interactions.

The design sacrifice of both the Open/Close principle, but also the principle of least knowledge is in my view the main reason why there are not much languages that offer what you expect.

Your example

Take the example of your overlap() and imagine there would be a way to add multi-methods (i.e. methods in the class and not free-standaing functions):

Imagine that you have implemented the Shape Circle Triangle and Retangle.
Imagine even that you've found a nice trick to take advandage of the symetry of the problem.
Your classes are fine and delivered in a library. Now the user of your library adds a new Shape, for example Octopus: how would this interact with your library: the user will not be able to change your library (close) - how can he/she extend it?

Conclusion : the solution should remain outside of the class

And if you consider the problem under this angle, the existing solution already offered for multiple-dipatch in C# seems to be the most promising to go.

It's always possible

There are lots of work-arounds to implement multi-methods in languages that don't support them:

Some use dispatch tables. The most impressing is imho in Alexandrescu's Modern C++ Design where template magic is used to make it happen almost naturally... provided that you're very versed in template programming.
Some hijack the build-in single dispatch to make a double-dispatch happen. All you need is a "bounce-back call" in which each class has the responsibility of performing one level of dispatching. Google for double-dispatch in your favourite language and you'll get it.

Since there are known solutions to implement it, it can for sure be automated and build into the language.

It's just matter of cost and sacrifice

Performance: the more dimensions in the dispatch, the slower will the dispatch be. It's either because of more indirections or because of complexer searches in larger dispatch tables.
Design: this design is not in the mind of the Open/Close principle since you'd need to add a new implementation when a new partner-class is derived: you have to know in advance the possible interactions.

The design sacrifice of both the Open/Close principle, but also the principle of least knowledge is in my view the main reason why there are not much languages that offer what you expect.

Your example

Take the example of your overlap() and imagine there would be a way to add multi-methods (i.e. methods in the class and not free-standaing functions):

Imagine that you have implemented the Shape Circle Triangle and Retangle.
Imagine even that you've found a nice trick to take advandage of the symetry of the problem.
Your classes are fine and delivered in a library. Now the user of your library adds a new Shape, for example Octopus: how would this interact with your library: the user will not be able to change your library (close) - how can he/she extend it?

Conclusion : the solution should remain outside of the class

And if you consider the problem under this angle, the existing solution already offered for multiple-dipatch in C# seems to be the most promising to go.

Source Link

created Jul 22, 2020 at 9:52

Christophe

80.6k
11
132
199

It's always possible

There are already lots of work-arounds to implement multi-methods in languages that don't support it:

Some use dispatch tables. The most impressing is imho in Alexandrescu's Modern C++ Design where template magic is used to make it happen almost naturally... provided that you're very versed in template programming.
Some hijack the build-in single dispatch to make a double-dispatch happen. All you need is a "bounce-back call" in which each class has the responsibility of performing one level of dispatching. Google for double-dispatch in your favourite language and you'll get it.

Since there are known solutions to implement it, it can for sure be automated and build into the language.

It's just matter of cost and sacrifice

Performance: the more dimensions in the dispatch, the slower will the dispatch be. It's either because of more indirections or because of complexer searches in larger dispatch tables.
Design: this design is not in the mind of the Open/Close principle since you'd need to add a new implementation when a new partner-class is derived: you have to know in advance the possible interactions.

The design sacrifice of both the Open/Close principle, but also the principle of least knowledge is in my view the main reason why there are not much languages that offer what you expect.

Your example

Take the example of your overlap() and imagine there would be a way to add multi-methods (i.e. methods in the class and not free-standaing functions):

Imagine that you have implemented the Shape Circle Triangle and Retangle.
Imagine even that you've found a nice trick to take advandage of the symetry of the problem.
Your classes are fine and delivered in a library. Now the user of your library adds a new Shape, for example Octopus: how would this interact with your library: the user will not be able to change your library (close) - how can he/she extend it?

Conclusion : the solution should remain outside of the class

And if you consider the problem under this angle, the existing solution already offered for multiple-dipatch in C# seems to be the most promising to go.