View Full Version : BlankClip and implicit last
Gavino
19th November 2008, 22:23
I have discovered an odd feature of BlankClip wrt implicit last.
A call of BlankClip() gives the expected default clip properties.
However, BlankClip (without brackets) takes its properties from last (if set).
This seems wrong to me - I don't think BlankClip should ever use implicit last.
It means that in a script like
<some filter chain>
x = last
y = BlankClip
...
clip y has its properties taken from x rather than the default (which is how I fell over the problem).
Experimenting further, and browsing the source code, I found it's a general feature of the parser.
A name with brackets is tried first as an arg-less function call, and then (as a last resort) with implicit 'last'.
A name without brackets (if not simply a variable) is tried first as a single-arg function taking implicit 'last', before trying it as an arg-less function. Why are the two cases treated differently?
Fizick
20th November 2008, 17:20
Why .... ? - Is a question for Ben and Klaus.
Real question is: What do you suggest? :)
Gavino
20th November 2008, 18:20
Real question is: What do you suggest? :)
My suggestion would be to make F behave the same way as F(), by changing the relevant code in ExpVariableReference::Evaluate to match that in ExpFunctionCall::Call. This would fix the BlankClip problem and similar problems with user functions, as well as making the language more consistent.
However, there might well be a good reason why it is the way it is, so we need to understand that first.
Fizick
20th November 2008, 22:57
I agree, that F should be equal to F(),
but what part to change?
Gavino
21st November 2008, 00:45
I agree, that F should be equal to F(),
but what part to change?
What, you want me to write the code too? :)
OK, here's what I meant. In ExpVariableReference::Evaluate (expression.cpp), change this code:
try {
// next look for a single-arg function taking implicit "last"
result = env->Invoke(name, env->GetVar("last"));
}
catch (IScriptEnvironment::NotFound) {
try {
// finally look for an argless function
result = env->Invoke(name, AVSValue(0,0));
}
catch (IScriptEnvironment::NotFound) {
env->ThrowError("I don't know what \"%s\" means", name);
return 0;
}
}
exchanging the red and blue bits, to this:
try {
// next look for an argless function
result = env->Invoke(name, AVSValue(0,0));
}
catch (IScriptEnvironment::NotFound) {
try {
// finally look for a single-arg function taking implicit "last"
result = env->Invoke(name, env->GetVar("last"));
}
catch (IScriptEnvironment::NotFound) {
env->ThrowError("I don't know what \"%s\" means", name);
return 0;
}
}
Fizick
21st November 2008, 18:29
i did not ask for precise code, but a question:
Must new Blankclip be equal to current implementation of BlankClip()?
or new BlankClip() must be equal to current impementation of BlankClip?
Gavino
21st November 2008, 19:37
i did not ask for precise code, but a question: Must new Blankclip be equal to current implementation of BlankClip()? or new BlankClip() must be equal to current impementation of BlankClip?
Ah, sorry Fizick, I completely misunderstood your question. :o
Well, at least we have a potential solution now. :)
In my view, the current behaviour of BlankClip is wrong and should be made the same as BlankClip(). Implicit last is not used for BlankClip(width=200) so it should not be used for BlankClip() either.
As I said, the problem is not in the definition of BlankClip itself (whose clip parameter is optional) but in the way the parser handles variable names. Specifically, it tries to interpret F as F(last) before it tries it as F(). My fix changes this order of precedence, making the behaviour consistent with the way explicit function calls are handled.
Implicit last should only be applied as the last ;) resort, when no other interpretation is possible.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.