Understanding Villegas-Gayley

Say there's a function with only DownValues (as an example). The objective is to inject some wrapper code to it. You want to replace the function definition with your own code, but allowing your own code to call the unmodified function. For example, you might want to add preprocessing or postprocessing. All this, without requiring to modify existing definitions, either because of style or because of a real limitation as in the case of system functions. This is where the trick comes in.

How to do it

You need to prepend a definition that only matches when a variable is in a certain state. Then, while inside your function, you dynamically localize that variable so that it doesn't match the definition. Many built-ins whose definitions you can't access, will always try your custom definitions first so you might not need to worry about "prepending" the values. Example

Unprotect[Expand];
warn = True;
p_Expand /; warn /; ChoiceDialog["Sure?"] := Block[{warn = False},
   Print@"I'm about to expand";
   With[{exp = p},
    Print@"I expanded, here you go";
    exp
   ]
 ]

In this last case, the variable warn acts as a guard that you can modify to turn this definition on and off, in case you are interested. Otherwise, for safety, it may make sense to localize it and make it unique, for example, with a Module, as in 

Module[{guard=True},
    fun[_]/;guard:=Block[{guard=False}, code] 
]

It seems the original version of the trick was intended to inject code in built-in functions. These functions live in the System` context. Your definition will also live in that context, since it is attached to the unprotected system symbol. As @Mr.Wizard warned in the comments, there's an evil lurking: the chance of Clear["Global`*"]. If your guard symbol lives in this context, then you will have a problem after clearing it. A solution that gets the best of both worlds is then

Module[{inside},
    fun[_]/;!TrueQ[inside]:=Block[{inside=True}, code] 
]

For those cases where the function returns unevaluated, you fortunately have the "cache bug" to prevent an infinite iteration. I don't think this "bug" is going anywhere, since this trick is used internally by Wolfram, and Update is a documented function.


Your post is actually several questions in one. I believe that in the future you should split such posts into several rather than grouping everything related into one.

One question appears to be about the placement of Conditions. Please see Placement of Condition /; expressions and post an answer if you have a fact-supported opinion about this. Regarding my code that you quote in the question I went with the RHS placement for the sake of line length for formatting.

Your proposed alternative doesn't work because the state of uq is inconsistent. Every call to the primary function will flip the state, therefore it fails entirely when the function is used repeatedly in the inner definition. Observe:

With[{uq = Unique[]},
 uq = False;
 func[x_] /; (uq = ! uq) := Print[{func[x], func[x]}]
]

$RecursionLimit = 20;

func[1]

{func[1],func[1]}

{func[1],Null}

{func[1],Null}

{func[1],Null}

{func[1],Null}

...

Also if you run your code multiple times you will get multiple definitions, all of which will interact and cause unintended behavior, though this could be corrected by using a named global instead of a Unique.

Since "Villegas-Gayley" has been design pattern for twenty years one could argue that it should be more recognizable and therefore more clear than alternatives. If you rewrite your question to focus on exactly what you think is unclear or counterintuitive about the Villegas-Gayley pattern perhaps we can address that. And unless or until you can provide a viable alternative there is little point is discussing hypothetical pros and cons.

Tags:

Evaluation

Recent Posts