Make l() optionally return structured output

updated summary

Added proposed flag

clarification

nitpick but i believe that in D8 for mixed return values where we know the different data types we're saying string|array instead of mixed.

Also, rather than try to make assumptions about what parts of the structure of l() the caller is looking for, can we just return $variables as-is post-sanitisation?

+ $variables['path'] = check_plain(url($variables['path'], $variables['options']));

I feel like rather than overwriting $variables['path'] we should add $variables['url'] and use/return that.

Looking good though :)

Y'know what's weird? Accessing an array once and setting a variable twice is faster than setting an array once, ie:

  $array = array('a' => 'b');
  $ref = &$array['a'];
  $ref = 'c';

Is faster than:

  $array = array('a' => 'b');
  $array['a'] = 'c';

Regardless, yeah we should profile #7 before we go off micro-optimising setting variables in different ways. It looks RTBC to me already but without performance stats who knows?

@Fabianx asked for tests in IRC so I'm tagging.

I think any micro-optimization is not worth it here:

200 links (first baseline vs. baseline); 2nd with #7 applied:

=== head-l-200-links..head-l-200 compared (5185b1712a8b6..5185b1d606b57):

ct  : 38,430|38,430|0|0.0%
wt  : 163,692|163,110|-582|-0.4%
cpu : 164,010|164,011|1|0.0%
mu  : 16,653,312|16,653,312|0|0.0%
pmu : 16,773,136|16,773,136|0|0.0%

http://www.lionsad.de/xhprof-kit/xhprof/xhprof_html/?run1=5185b1712a8b6&run2=5185b1d606b57&source=drupal-perf-fabianx&extra=head-l-200-links..head-l-200

=== head-l-200-links..structure-render-l--7 compared (5185b1712a8b6..5185b2059b5c4):

ct  : 38,430|38,430|0|0.0%
wt  : 163,692|163,484|-208|-0.1%
cpu : 164,010|164,010|0|0.0%
mu  : 16,653,312|16,654,808|1,496|0.0%
pmu : 16,773,136|16,774,560|1,424|0.0%

http://www.lionsad.de/xhprof-kit/xhprof/xhprof_html/?run1=5185b1712a8b6&run2=5185b2059b5c4&source=drupal-perf-fabianx&extra=head-l-200-links..structure-render-l--7

Little more memory used and no measurable difference (maybe even slightly faster) ...

=> RTBC (from a performance perspective)

Still needs tests

writing tests..

Tests.

RTBC per #10:

Has nice test coverage, makes it possible to use l() to return the structure to re-use for theme_more_link and theme_link, keeps things fast and makes markup-utility functions possible.

=> RTBC

I find it problematic that this introduces a change to a common API function that returns a different variable type depending on the arguments *as an API.*

The only other place in PHP/Drupal where this really happens is things like strpos(), node_load()/entity_load(), and old-style iterators like mysql_fetch_object() to indicate some sort of exception.

I'd prefer to see this as a helper returning structure for all three l(), theme_link(), theme_more_link() etc, rather than a first-class API function.

@c4rl re #16 could you explain your 'helper' idea a bit more?

The problem you explained seems clear, though the solution does not.
A concrete example would probably be best because 'helper' has about as much meaning as 'block' or 'container' does. Also, I heard l() was a 'helper' from a few people... so for me that made things extra confusing.

I'm having a look at this over the weekend. I think I have a good idea of what @c4rl is talking about in #16.

I was playing around with this, and I wasn't sure that what I was doing was even useful until a patch is committed elsewhere to formally enable separate prepare/render phases in drupal_render() - essentially the whole "drillability" issue.

All I discovered is that rather than l() returning structured output, it is likely that #type link will have its current internal logic prepended to the logic inside l() inside some "drupal_prepare_link()" style function (excluding the final line that concatenates the link markup together) and that l() will stay the same as it is in HEAD with an extra comment along the lines of "This logic is the same as drupal_prepare_link() but is in-lined for performance reasons".

#2044105: Introduce #alters for \Drupal\Core\Render\Renderer::render() this could be relevant to #type 'link', the "optional structured data" thing could be just running the alter hooks for #type 'link'.

Call me crazy, but l() could one day just be a wrapper around a #type 'link' render array.

Updated issue summary.

Just want to bump this and see if it's still relevant in the 'new world' of l() being changed so much.

Don't think we have the steam or need to get this in to 8.x.x so postponing to D9 or possibly closing as there may no longer be a need for this.

I think we close that, l() is dead ...