Re[2]: Incorrect newline counters

B> that html is not the only output target). I have no faith that
B> these  patches  will be transparent for all users. The risk of
B> breaking  someone's  output  to  support  this  proposal seems
B> unwarranted   to  me,  particularly  since  its  aim  is  more
B> pendantic than productive IMHO.
What  risk?  What are you talking about? Output is not changed at
all  - I only offer to remove unneeded \n's in PHP code (they are
not echoed) and after ?> (they are ignored too by PHP istself) to
synchronize   compiled   template   code   with  source  template
line-by-line. No more, no less.

I  do  not understand you at all. Maybe my english is too bad and
explainations are too short (my original language is Russian)?

You say below that compiled template code must be human-readable.
I agree with it, but, first, it's too late to think about it (see
real  compiled template - they are practically too complex), and,
second,  additional  \n's do not improve readability of code more
than 10-15%, but they trash the debug process great.

I'd  like  to  head Smarty developers words too - Monte Ohrt, for
example.

P.S.
Theorem:  "If  any  compiler  does not include "\n" string in its
code  (or  chr(0x10)  etc.),  it  cannot  affect  to  line number
synchronization at all." (-;

-- 
Best regards,
  Dmitry Koteroff.

B> --- messju mohr <[email protected]> wrote:
>> On Mon, May 31, 2004 at 03:31:23AM +0400, Dmitry Koteroff wrote:
>> > RA> Basically,  the  smarty templates are geared so the resulting
>> > RA> output  is the same as the template, and is a higher priority
>> > RA> than the compiled template itself.
>> > Aargh!
>> > 
>> > What do I see in _compile_foreach_start(), for example?
>> > 
>> >   $output .= "if (isset(\$this->_foreach[$name]))
>> unset(\$this->_foreach[$name]);\n";
>> >   $foreach_props = "\$this->_foreach[$name]";
>> > 
>> > WHAT IS THIS? Why \n? It breaks line number!
>> 
>> yes, but nobody here does really seem to care, except of you.

B> Actually, I'm certain that messju is aware that many of us care very
B> much -- but I'm certain too that he is also aware that we care about
B> completely different issues surrounding the topic. Smarty MUST ensure
B> that the template *output* is line-for-line what was intended in the
B> template source. The compiled files are of little consequence since
B> they are not the end target of the template process. In many ways they
B> are incidental. Yes, Smarty is playing the role of a meta-language
B> writing code that writes our output; but the code it writes is not our
B> objective--it is the output of that code that is crucial.

B> The thing is, is that the compiled code is just that: it is analogous
B> to the object form of source for a formally compiled program/language.
B> What would you do to debug from object code in that case? You would
B> have to have a suitable symbolic debugger which had access to special
B> symbol tables developed at compile time. If the compiler fails, it
B> tells you where your source went wrong. If the runtime fails, you are
B> stuck with a *very* different sort of process to trace back to your
B> sourcecode. In other words, as already has been suggested, the place to
B> search for errors is in the sourcecode at compile time -- mucking with
B> the object files is not how one should spend their debugging time if
B> they can avoid it. To this end, I agree that it is not feasible (or
B> desirable) to have Smarty try to catch all possible errors. There are
B> things we have to live with and we manage them through process and
B> convention. (For example, most templates are coded using an iterative
B> testing process, so finding bugs is usually straight-forward: review
B> your most recent edits.)

B> In Smarty terms, wading into the compiled templates to debug them is
B> the absolute last-choice one would wish to make. Since it is more
B> important to preserve line-handling for the sake of output the best
B> thing is to at least make the compiled code human readable. I've been
B> using Smarty for years and can say that I've only needed to dive into
B> the compiled sources a handful of times.

B> From what I've witnessed, the present day line handling is the result
B> of a lot of give-and-take over the years based on many users
B> experiences on wide ranges of systems and usage patterns (remember too,
B> that html is not the only output target). I have no faith that these
B> patches will be transparent for all users. The risk of breaking
B> someone's output to support this proposal seems unwarranted to me,
B> particularly since its aim is more pendantic than productive IMHO.

B> Greetings,
B> xo boots


	
		
B> __________________________________
B> Do you Yahoo!?
B> Friends.  Fun.  Try the all-new Yahoo! Messenger.
B> http://messenger.yahoo.com/ 

-- 
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php