"hijackable"/"customizable" keyword for solving the "customized algorithm" issue?

[Steven Schveighoffer via Digitalmars-d]

On Thu, 15 May 2014 13:08:56 -0400, monarch_dodra <monarchdodra at gmail.com>  
wrote:

> On Thursday, 15 May 2014 at 12:16:52 UTC, Steven Schveighoffer wrote:
>> On Thu, 15 May 2014 02:05:08 -0400, monarch_dodra  
>> <monarchdodra at gmail.com> wrote:
>>
>>> "move" will also delegate to "proxyMove".
>>
>> This is the correct solution IMO. The principle of least surprise  
>> should dictate that a.foo should always mean the same thing. All that  
>> is required to enforce this is to make the "hook" function have a  
>> different name.
>
> The issue(s) I have with the "hook must have a different name" is:
> 1. In the algorithm implementation, you must explicitly test for the  
> hook, which, if we want to expand on, would turn all our algorithms into:
> void foo(T)(T t)
> {
>      static if (is(typeof(t.fooHook())))
>          return t.fooHook();
>      else
>          ...
> }
> 2. The "overriden" hook is only useful if you import the corresponding  
> algorithm. So for example, in my 3rd pary library, if my type has  
> "findHook", I'd *have* to import std.algorithm.find for it to be useful.  
> Unless I want to make a direct call to "findHook", which would be ugly...

Obviously, foo is not a good example for hooking. This problem only exists  
if the functionality of the module-level function exceeds that of the  
member. The above does not have any overloads, and basically does one  
thing.

I did consider the fact that you would have to import the module-level  
function in order for it to be part of the API, but that's how the system  
works. It would be nice to say "if you import module x, then a.foo has  
more functionality, if you don't, it's limited to this one aspect," but I  
don't think that's possible. It's not a perfect solution, but the only one  
that makes sense to me.

-Steve