**andr55** wrote:

(In reply to Brad Jorsch from comment #9)
> (In reply to andré from comment #8)
> > So you are saying that problems with the implementation of these new
> > features interfere with this extension ?
> 
> It's not a problem with those features, it's a design requirement.
> 
> We had to deal with that requirement when creating Scribunto, too.

Evidently.  And it works very well, at least on pages I've seen using it.  Such modules can be a tremendous improvement over pure templates.

> > I'm assuming that all this extension does is scan the page, taking the
> > variable definitions and replacing all instances using the defined
> > variables, before any other parsing of the page.  The result is a page that
> > shows no evidence of the extension.
> 
> I haven't checked, but I'd imagine the model is more that when the parsing
> process calls the hook for #vardefine it sets some internal state, and when
> it calls the hook for #var then it returns that internal state. Much like
> how with Cite a <ref> sets some internal state and <references> uses that to
> construct a list of references.

It would be setting a value for a token, and replacing tokens with that value.  Simple text replacement, as it passes through the page.  There are some more complicated options, but they could be ignored by WP if difficult to implement.  For instance, there could be a bar to using recursion.

> > Maybe there needs to be a processing priority established ?
> 
> Let's not add even more passes to the parser. The Parsoid folks already want
> to do that for Cite (and do do it in Parsoid).

But additional passes can be a very effective way of simplifying the problem.  Often with little or no cost in performance.

> > Maybe you can explain how any problems with the new VisualEditor and Parsoid
> > are not orthogonal to this extension ?
> 
> Because wikitext needs to be parsed?

Logically, the simplest solution for extension:Variables is to have a priority parsing pass to itself.  Once that is done, the resulting page shows no evidence of the extension.
If there is a relatively straight-forward way to signal the use of the extension in the page (such as a definition near the beginning of the page), the performance hit for other pages should be minimal if any.
Maybe the parser could do an initial scan of the page to enumerate all the extensions/modules used in the page (if it doesn't already), and then do parsing passes according to an appropriate priority.  Many but not all could be done in parallel.  Extension:Variables being an obvious exception.
It's not rocket science.  (To experienced programmers, at least.)

If there is a problem with how extension:Variables is implemented, I'd be interested in writing a similar very simple equivalent, that does nothing more than act as a preprocessor, replacing one or more variables with literal text in a single pass.  In my mind that is all that most uses of such an extension would be anyway.  And it does fill a void, between templates and modules created with Scribuntu/Lua