in reply to hrm, Eval::Compile

but it means the plugins would be a lot harder to code

No it doesn't -- the way you code plugins wouldn't change one bit

Replies are listed 'Best First'.
Re^2: hrm, Eval::Compile
by Logicus (Initiate) on Jul 20, 2011 at 06:30 UTC

    Ok, so I've gone away and had a think about that and I think I can see a way of organising it so that the plugins can remain the same, however there is still another problem.

    lets say you have a situation like this:

    (foo) <bar><x/></bar> (/foo)

    Where for instance foo does a database lookup and for each row of the database returns <bar> with the x value filled in. Now we have a certain number of <bar> directives to compute, the number of which is unknown until foo has been computed.

    Each time the program runs there could be a different number of rows retrieved from the database, so unless we compile each time, negating the point of the excercise, there is no way to know how many instances of the compiled <bar> directive to include in the precompiled file.

      Each time the program runs there could be a different number of rows retrieved from the database, so unless we compile each time, negating the point of the excercise, there is no way to know how many instances of the compiled <bar> directive to include in the precompiled file.

      What? That is a simple foreach loop, as already demonstrated in Re: H.O.P && aXML, Re^4: RFC : Abstraction Markup, Re^7: H.O.P && aXML, Re^7: H.O.P && aXML

        I disagree, however I cannot currently figure out how to describe exactly why. I will think about it more and see if I can come up with a concrete example of the problem, or figure out why I am mistaken.