Make WordPress Core

Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#13395 closed enhancement (fixed)

Introduce _ex to replace echo _x

Reported by: westi's profile westi Owned by: westi's profile westi
Milestone: 3.0 Priority: normal
Severity: normal Version: 3.0
Component: I18N Keywords: has-patch 2nd-opinion
Focuses: Cc:

Description

We have a lot of echo _x around and about it would be much cleaner to have _e_x to do this.

Attachments (1)

_e_x.diff (19.1 KB) - added by westi 15 years ago.
a patch

Download all attachments as: .zip

Change History (9)

@westi
15 years ago

a patch

#1 @filosofo
15 years ago

I'd recommend _ex over _e_x:

  • Consistent with how _n and _x are combined into _nx
  • [something]_[something else] seems usually to connote that one function calls another, which doesn't really happen here (echo isn't a function and doesn't transform the value in question)

#2 @nbachiyski
15 years ago

I am also for {{{_ex()]}}.

#3 @nacin
15 years ago

(In [14647]) Introduce _ex(), a hybrid between _e() and _x() -- translate with context, then echo. props westi, see #13395.

#4 @nacin
15 years ago

  • Resolution set to fixed
  • Status changed from new to closed

#5 @hakre
15 years ago

I have a suggestion for those who want to make the next step:

<?php _e(x, 'Slug', 'Taxonomy Slug'); ?>

as in:

function _e() {
  $p = func_get_args();
  $f = '_' . array_shift($p);
  echo call_user_func_array($f, $p);
}

not really, this is just for the taste of it.

btw, does "constant string usage" throw any warning with wordpress requirements?

#6 @hakre
15 years ago

Related: #13399

#7 follow-up: @nacin
15 years ago

Yes, constant string usage throws a E_NOTICE. That suggestion seems invalid to me, it only makes things more complicated.

#8 in reply to: ↑ 7 @hakre
15 years ago

Replying to nacin:

Yes, constant string usage throws a E_NOTICE. That suggestion seems invalid to me, it only makes things more complicated.

complicated ... i would say that this can be the one or the other.

let's play and compare one by one:

echo _x(

Made short:

_ex(
_e(x
_(ex

in terms of complexity all four variants have pretty much the same. all three short ones are especially totally equal when it comes to the shortcut identifier length .

maybe the first one is the easiest to understand, because it's clear that something is send to output. but that aside, as this is about removing the echo.

all 3 short variants have the same length and even look pretty much the same. let's say, they save us the same amount of typing. thanks to standard wordpress settings, E_NOTICE is not an issue here. And even if it would be, just define x as 'x' and so on would solve that (to spare us the quotes).

but even better, by implementing some little parser, this could be further improved (keep in mind that this is very much under the theoretical model, that typing less to invoke a function is more important regardless anything else). i dunno whether we have _() in use or not. let's assume it can be used

sample code:

_(ex, 'Slug', 'Taxonomy Slug');

aka

_(ex

as in:

function _() {
 $p = func_get_args();
 $f = $p[0];
 $l = strlen($f);
 $d = 'wp_shortcutfunc_';
 while ( $i<$l && ($d.= $f[$i++]) )
   if (function_exists($d))
     return call_user_func($f, $p);

 # since wp is php 4, call an undefined function 
 # instead of throwing an execption:
 call_user_func($d);
}

function wp_shortcutfunc_e($p) {
  p[0] = substr($p[0], 1);
  if (!strlen(p[0])) { #echo parameter(s)
    array_shift($p);
    foreach($p as $s)
      echo $s;
  } else { #something left to parse
    echo call_user_func_array('_', $p);
  }
}

function wp_shortcutfunc_n($p) {
  # quick and dirty here for _n & _nx,
  # let's say you can not combine with n
  # any further
  if ('nx' == array_shift($p)) {
    return call_user_func('_nx', $p));
  }
  return call_user_func('_n', $p));
}

function wp_shortcutfunc_x($p) {
  return call_user_func('_x', array_splice($p, 1));
}

this would be an function-name based shortcutting machine. it's not perfect (right now it can not overload itself so the parser can't change the parsing which could be a usefull to gain more modularity), but for the example, it will save you from writing any more echo and is already somehow flexible. I would say it has about the same level of modularity as the current system has but it's more easy to extend in two directions: combinations of functions (just add an e in front if you want to echo some other function out) and adding new functions.

This works now with just some lines of code.

_(e, 'Hello world'); // <- hello there :D
_(x, $param1, $param2);
_(ex, $param1, $param2);
_(n, $param1, $param2);
_(en, $param1, $param2);
_(nx, $param1, $param2);
_(enx, $param1, $param2);

pretty impressive for those some 30 lines of code, right? combination is not perfect in the end, but it's pretty straight forward: the smaller a function name is, the higher is its priority in combinations. so for the implementation of _nx, there was need to actually parse the input in wp_shortcutfunc_n. but that can be a seen as a sign of shortcomming in naming the existing shortcut function names. whatever, the parser can handle that.

ready for some more fun?

let's extend this, because when it comes to the end of day, all this is about input, output, so echo and return while calling some functions. so what's missing here would be to actually grab output and return it or do invokes and calls. let's introduce two new, very simple shortcut functions to step on with the new "shortcut machine":

c - as for call, namely:
... ca - with array of parameters
... cp - with parameters
... ci - invoke on parser

the call shortcut introduced complexity, so some sample usage for clarification first:

_(ca, $callback, $array_of_parameters);
_(cp, $callback, $param_1, $param_2, ... );
_(cie, 'hello word'); // will invoke e which will do echo

this one would help to streamline our own implementation a bit as well. i do not do that here in the examples but maybe i'll attach some sample code where i would. please note that this code is just typed in as a mock-up, i have not run that.

r - as for return output

this is just to loop some echoed stuff back in, e.g. for template tags (well those could have benefited from something comparable in the beginning ... ) just two examples here:

_(e, 'This Post MD5:', md5(_(rcp,'the_content')));

or for the double-power of both approaches:
_(e, strrev((_r('the_content')));

here is the pro-forma code:

function wp_shortcutfunc_c($p) {
  if ('ci' == substr($p[0],0,2)) {
    return _(substr(array_shift($p),2), $p);
  }
  $c = array_shift($p);
  $f = array_shift($p);
  if ('cp' == $c && ($c = 'ca'))
    $p[0] = $p; # if that works?
  if ('ca' == $c || 'c' == $c)
    return call_user_func_array($f, $p[0]);

  wp_shortcutfunc_c(array('__UNDEFINED__', $f)); # do stack overflow, reached an end here
}

function _r() {
  $p = array_get_args();
  $p[0] = substr($p[0], 1);
  ob_start();
  call_user_func_array($c, $p);
  return ob_get_clean();
}

function wp_shortcutfunc_r($p) {
  $p[0] = substr($p[0], 1);
  array_unshift($p, '_');
  return call_user_func('_r', $p);
}

just imagine all the possibility..., remember all those escape-this and esc-that? this is a short-cutters paradise but i stop here since this is enough for some minutes typing fun. hopefully this is of some inspiration.

take care, it's not always shorter:

_(e, 'yay'); 
echo 'yay';

especially not if I had typed that according to the wp standard. would we would have saved in typing by not adding space everywhere where see fit... :) .

Note: See TracTickets for help on using tickets.