Calling internal function from plugin with same name

[Gavino]

For something I am working on, I want to have a plugin function with the same name as an internal filter (basically as a sort of wrapper).

The catch is I also need to invoke this internal filter from within my plugin, but I cannot simply use env->Invoke in the usual way, since my plugin function masks the internal one.

Is there any way to achieve what I want?

[IanB]

Sadly no :(

[Gavino]

That's a pity - it would be nice if there was something like env->InvokeBuiltIn(...) or just an optional flag on Invoke.
Consider it a feature request :)

In the end, I got round it by making my plugin function have a slightly different interface to the built-in one, since Avisynth is intelligent enough to distinguish overloaded functions via parameter types and names.

[stickboy]

Wasn't there a pseudo-namespace system added to automatically prepend the DLL name to exported plug-in functions? It doesn't help here, but why doesn't that system apply to internal functions too?

Edit:
Yeah, and my questions from 2004 went unanswered:
http://forum.doom9.org/showthread.php?p=461466#post461466

[sh0dan]

@Gavino: Overriding built-in function is generally not a nice thing to do, since you potentially can break a lot of peoples scripts, if your plugin has a bug, or doesn't behave exactly as the built-in function. So you'd better have a d*mn good reason. :D

PS. Just found out this is actually called Monkeypatching (http://www.codinghorror.com/blog/archives/001151.html).

[stickboy]

It's not necessarily true that someone writing a plug-in or script function is intentionally overriding a built-in function. It can work the other way; a new version of AviSynth can add a built-in function that clashes with existing plug-ins/scripts.

AviSynth already allows the collisions; IMO there might as well be a mechanism so people can reliably call the built-in functions and avoid monkeypatching.

The reason I'd like to see it is so that scripts can provide glue functions that work across AviSynth versions. For example, if I had some function Foo() that eventually got incorporated into AviSynth:
function Foo()
{
try {
# Call the internal version if it's available.
AviSynth_Foo();
} catch (msg) {
# The version of AviSynth is too old; try doing it manually.
...
}
}

[Gavino]

@Gavino: Overriding built-in function is generally not a nice thing to do, since you potentially can break a lot of peoples scripts, if your plugin has a bug, or doesn't behave exactly as the built-in function. So you'd better have a d*mn good reason. :D

PS. Just found out this is actually called Monkeypatching (http://www.codinghorror.com/blog/archives/001151.html).
I'd never heard the term 'monkeypatching' before (thanks for the link), though I'm familiar enough with the underlying concept. I agree with you that it's something to be used carefully, and rarely. :cool:

In the case of my plugin, I thought long and hard before opting for the 'monkey' path (even though it was more work for me).

First, I should explain that my plugin (GRunT) is an extension to the run-time/conditional environment, a subject I understand you have more than a passing acquaintance with, sh0dan. :D So I'm very glad to see you join this discussion.

In my design, I was careful to extend, rather than replace, the existing functionality. An important objective for me was 100% backwards compatibility - all existing (working) scripts should behave exactly as before. Using a 'wrapper' approach helps to achieve that.

Of course, I could still have chosen to use different filter/function names (eg GScriptClip instead of ScriptClip) and that was my first thought. However, I was swayed by these reasons:
GRunT's focus is on increasing usability, and having two sets of names detracts from that;
the plugin includes a bug-fix to the standard filters, which should preferably be picked up without script changes;
since conditional filters can interact in surprising ways (I'm sure you know this only too well :)), it seems prudent to avoid the possibility of mixing old and new versions in the same script (and many uses of ScriptClip et al are inside 3rd-party functions, unseen by users).
Even if you perhaps end up disagreeing with my reasons, I hope you will see that my decision was not taken lightly.
(And I'd really value any comments you have on the plugin itself.)