Am 31.07.2018 um 20:31 schrieb Thorsten Froehlich:

>> That said, "as designed and documented" doesn't necessarily mean that
>> it's free from issues that might warrant fixing. It might just be that
>> there's a problem with the design.
>>
>> And I for one would argue that that's indeed the case (presuming dot
>> notation has been excluded from functions by design rather than by
>> oversight). Because - evidently - this behaviour goes against user
>> expectations.
> 
> It is logically correct in a properly (given you worked on the tokenizer you
> know what I mean) designed parser: Functions cannot access declared values
> because functions persist after parsing. This would require substituting the
> preprocessor-level declared variable with the value of the variable. This value
> would be a vector, which isn't supported.

I don't see an issue there.

It would be a valid point if the dot operator were to be implemented as
an operation in the function VM.

However, since we are talking about `SDL_VARIABLE.x` (and siblings)
here, and not `FUNCTION_PARAMETER.x`, I see no sound reason why the
function parser couldn't resolve the operation at parse-time.

The rule would be pretty simple:

If the token is an SDL variable holding a vector or colour, take a peek
at the next token. If that token is a dot, expect a component name, and
inject the respective value into function. If the token is not a dot (or
the component name is invalid), raise an error.

Post a reply to this message