Convert theme_*() functions to tpl.php

I'm pretty sure this makes little sense for several theme functions. Please open separate issues as bite-sized tasks.

At first glance, I disagree.

First, I feel that will damage performance, and really disable the advantages of using an opcode cache like APC. Benchmarks with APC have often shown a 10x improvement. I may be wrong, but I think a lot of this would be disabled using the dynamic includes of tpl files.
I don't have the numbers, but it seems that opening and closing a bunch of files repeatedly has gotta be harder that recalling a compiled function from memory. There may be optimizations behind the scenes I'm unaware of.

Second, surely there are some theme functions that contain code, logic, and calls to sub-theme functions. That stuff does not belong in tpl files. There are cases where a function is a better place for code.
No way would theme_links() benefit from this treatment.

Third, as a coder, I find multiple tpl files floating around to be trickier to work with than one (or even three) module files containing functions I can access with an IDE. It just makes scanning available code a lot slower to work with.
You say it will bring more visibility ... in the last few months of working with Drupal6/Views2, I've gotta say it has the opposite effect. Those tiny code fragments are badly out of context and in unintuative places. ... to my way of working.

I can scroll down a module listing in a minute and see both what themes are available and what they do. That is much harder with lots of files containing code fragments.
Of course I'm speaking as an actual developer here, and your suggestion may find more support with non-coders :-/

Abstaction of code from presentation is one thing, but it's reaching a really trivial level. I've seen templating systems torn apart by this approach before.
I mean views-view-field.tpl.php this is just annoying!
As a general rule, how about converting theme functions to theme templates only in cases where it would produce significantly more characters of HTML than characters of PHP including documentation and formatting.
So small (and 'tight loop') ones like theme_menu_item_link() are also better off as functions as well as the big ones.
Metrics are not the full answer, but neither is a blanket rule to always use a "single way of doing things" when several viable (or better, appropriate) methodologies are available.

.dan.

sorry about the status

I changed the status (back because I overwrote it by accident in a cross-post) to agree with Damien that if there are changes to be done, they will have to be done in individual issues. per-func, or at least per-core-module in order to actually happen. So you can submit patches against them individually. It's the only way changes can go in, and is a way forward.

1. Like I said, I don't have the metrics. You have a proposal, I ask you to provide metrics that will show that this far-reaching structural change will not be detrimental (in an opcode-cache environment) ;-)

2. I totally admit that this is a developer-centric, or personal preference to not juggle dozens of files at once. All that means is that my opinion is a bit different form your opinion. There may be people uncomfortable with PHP who find it more convenient to have many small HTML+PHP files open at once. I'm just saying I prefer having context, editability, IDE shortcuts, less open windows and easier change control.

3. theme_preprocess is very awkward in small cases. In some cases it would triple code and add seriously unneccessary abstraction to something that could be done in three lines.

Not sure what your point is, but I've been a themer doing core theme overrides very happily in template.php since 4.6. I've even written a tutorial on it. It's REALLY easy. It works great. I can evaluate a contrib theme at a glance and see the features it adds just by scrolling down that file.
The whole thing about the theme() function is that nothing is "trapped in code" at all - it can all be overridden. That's why it's great, and already does anything you want. You just need to know the magic word. ( It's s/theme_/templatename_/g )

BUT there are certainly certain cases that could benefit from more visibility to non-coders. theme_search_block_form() would be a good target. ... Oh, it's already done. Cool. That makes sense. The links I gave above do not make sense.

So, as Damien suggested, find the individual functions that deserve a rewrite and consider them individually. But I don't think there is a one-size-fits-all code methodology mandate to be applied here.

It is out of question that theme functions are faster than templates. Each theme() call that uses a template file includes at least one preprocess function call and one file include, while a theme() call towards a theme function skips both of them for just one function call. Now, the point is how much. For a page.tpl.php which is loaded exactly once per page load, it wouldn't matter. If theme_placeholder, for example, would be a template, I am quite sure perfomance would suffer noticably as it can easily be called dozens of times per pageload.

So, conerting *all* theme_ functions to templates won't make any sense IMO. There might be some cases where templates make more sense, but these have to be identified and patched individually.

Converting all theme_* functions to templates would vastly decrease performance.

However, #399702: Registry: replace files[] with include[]/exclude[] might aid themers to maintain theme override functions more easily.