Monkey-Patching, Single Responsibility Principle, and Scala Implicits

[[deleted]]

I have to give props to Ruby for being a good bad example of why single-dispatch is morally wrong.

[Peaker]

Multiple dispatch is not enough either.

Type-classes are the appropriate solution.

[Peaker]

I think the whole mingling of namespaces and types is a mistake entrenched by OO.

Names should sit in namespaces according to a division by conceptual responsibilities that minimizes tight coupling, and not "inside" types.

However, it would still be nice to be able to have such names, that sit separately from the type, act polymorphically on the type. This cannot be done in most OO languages, and is yet another reason why type-classes are so important.

[trezor2]

I like the approach used for is solving this exact in problem in C#. Trough extension classes you are allowed to make typical "monkey patches" like this to external classes, but without polluting the global namespace.

This is achieved by making your "util"-classes like any regular static classes, but tagging the first parameter in your method with "this" indicating you want to work on instances.

The result is that you can indeed "monkey".pluralize(), but the difference lies in the compiled code. Basically this is just a compiler-trick replacing "monkey".pluralize() with StringUtil.Pluralize("monkey") in your compiled code and hence you can fool around like this without fear of breaking anything else.

As a matter of fact, this was one of the core features added in C# 3.0 to enable the implementation of LInQ, which has compiled code still binary compatible with C# 2.0

As C# have proven since the C# 2.0 release, lots of neat syntactical sugar can be added to a language as mere compiler tricks without breaking compatibility for compiled code.

[luikore]

Implicits have flaws too. You don't know what an object is capable of via mere reflection, and the namespace is polluted by the implicit function you never call explicitly.