Re: Template Proposal

On Friday, November 9, 2001, at 12:18 PM, Wolfram Kriesing wrote:

TABS-or-SPACES when are we getting over this? is this topic now coming up every once in a while?

I'm not arguing one or the other, I'm arguing that there's even an issue over such a thing. If there wasn't, there wouldn't be the recurring argument.

functionality is more of importance

And I'm saying that the functionality of Smarty, ITX, AT, FastTemplate, etc. should be welcome by PEAR. Sure there is a duplication of effort between them, but they each have stated different goals and different advantages. If I needed multi-byte support and didn't have the time to wait for or contribute to a template class that doesn't have it, what would I do? If the one knighted by PEAR as supreme doesn't have it, well, looks like I won't be using the PEAR class then. It comes down to there being more than one way to get things done, and enjoying the flexibility to choose from those various ways. What if PEAR were to create a separation between CORE and EXT (external) libraries, and external classes would be accepted on a compliance basis (at least in key areas like elegant error handling). Then PEAR could have its PEAR_Template class and we wouldn't have to exclude the horde of other good solutions. This is what I've been working on with a project of mine. Instead of duplicating the effort to produce a completely unified API when that isn't entirely necessary, I simply throw another class into EXT, and away I go. I obviously have standards to hold the new classes up to, but I find it an effective solution for the most part. Lux

NO! We need the coding standards - although I would like to see tabs used instead of spaces - that way when you're working on a class, if you like your indentation set to 10 spaces you just alter the tab stop. If you like it one space, you alter the tab stop. The next developer can set it to exactly what he wants. I think you get my meaning :-)

Yeah, I get your idea. But see the following example: <?php foo("value1",

    "value2"
    );

?> This snippet only looks good with spaces or with a tab width set to 4 spaces. When using a different tab width, "value2" will be indented differently => tabs are evil :-).

Then add more spaces. <?php foo (

     "value1",
     "value2"

); ?> The 'evil' tab doesn't 'get us' that way, and it's cleaner to read. My argument for less restriction on formatting rules is simply that they were chosen based on the subjectivity of the few who started PEAR and may not correspond to the way a lot of developers work. I've been coding a certain way for years now. Nobody's ever complained. In fact, they've done quite the opposite. I would find myself less productive if I had to remove the spaces between my method calls and their parentheses "methodName() v.s methodName ()", or if I had to start putting my curly braces on the line after the function declaration. I think the former in the above example detracts from legibility, yet it is the PEAR standard. Or if I had to switch to spaces. I've tried that, and it sucked. So I'm a bit of stickler on my personal coding preferences. I think we can set guidelines that are still clear enough, yet flexible enough to accommodate slight differences in coding style, that some joe can't come along with indents of 1 space and say "here ya go". Actually, the first time I read about PEAR and saw all those formatting rules, I said to myself "fuck that" and didn't bother looking at it for quite a while afterwards. And as for ensuring it's a high quality repository, keep the approval process. Don't let just any joe go committing new Forums and such that have no place in PEAR, or some class that is only half functional and kind of shifty. I think it's a waste of time arguing over whose template engine should become the standard. The "we already have one of those, sorry" rule may only end up hurting PEAR in the long run, when some guy with a new class moseys on in and is refused because we don't need another template engine, and his engine ended up having a really cool idea we didn't notice to consider so we lose out. Lux

- Martin -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, e-mail: pear-dev-unsubscribe@lists.php.net For additional commands, e-mail: pear-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net

-- Wolfram -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, e-mail: pear-dev-unsubscribe@lists.php.net For additional commands, e-mail: pear-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net