> Add a couple parens and its completely implementable in userland If we could autoload functions, I bet that's what everyone would be doing.
At the moment, no one is able to commit to that pattern, because it doesn't scale - you can't just keep adding to a list of global functions (and files) that get aggressively loaded whenever you render a view, even if each view uses only one or two of them... So in practice, you minimally end up with something like this: <?php use My\Stuff\EscapeFunctions as e; ?> <?=e::html($str) ?> <?=e::attr($str) ?> <?=e::text($str) ?> ... But that isn't really practical either, since you can only cram so many functions into the same class - at which point you start adding more classes... <?php use My\Stuff\EscapeFunctions as e; ?> <?php use My\Stuff\OtherFunctions as o; ?> <?=e::html($str) ?> <?=o::stuff(...) ?> It quickly gets ugly, messy and confusing. Then I start thinking about crazy solutions like tokenizing the template file first and dynamically adding require_once statements for any functions discovered being used, which would be more convenient, but quite overly complex for such a small problem - and we're still talking about occupying the global namespace with lots of functions. And so you likely end up accepting that it's ugly and inconvenient, and you resign yourself to use-statements and static methods, or fully-static classes, which I've taken to referring to as "psuedo-namespaces", since we're really abusing classes as a kind of namespace for functions, just so we can get them to autoload. Functions just aren't all that convenient or useful in PHP, because they largely depend on manual use of require_once, which feels really ugly and old-fashioned (since everything else autoloads like it's supposed to) - and it isn't even always possible, since, for example, you can't (reliably) know where a Composer package is located relative to your project or package; it depends on whether your project is currently the root package (e.g. under test) or an installed package in the vendor-folder. I really like pure functions - they're neat, simple and predictable. In Javascript (and other languages) I always use functions first and resort to classes only when there's a real clear benefit. In PHP, I feel like I'm almost always forced into using classes for everything, mainly because that's what works best in PHP and creates the least rub. This has been bothering me for many years - and I wish that I could propose a solution, but I really don't have any ideas. Can we do something to improve and encourage the use of functions in PHP? On Sat, Jun 18, 2016 at 12:27 AM, Ryan Pallas <derokor...@gmail.com> wrote: > On Fri, Jun 17, 2016 at 2:23 PM, Thomas Bley <ma...@thomasbley.de> wrote: > >> you can simply add the context to the current output operator: >> <?=html($str) ?> >> <?=attr($str) ?> >> <?=text($str) ?> (=strip_tags) >> <?=js($str) ?> >> <?=css($str) ?> >> > > Look at that. Add a couple parens and its completely implementable in > userland now with no language changes required. > > >> Regards >> Thomas >> >> Stanislav Malyshev wrote on 17.06.2016 22:14: >> >> > Hi! >> > >> >> Most of output code is an output of properties of database entities, and >> >> only in some cases it's needed to concatenate HTML into string and then >> >> print it with unescaped output. Escaped output operator can be useful. >> Also >> >> we output data not into the void and not into simple text file, but into >> >> HTML-document which has a certain format (markup). Also this is logical >> - >> >> to have both forms, escaped and unescaped. >> > >> > This has been discussed on the list a number of times. Main issue with >> > this kind of proposals is that escaping is context-dependent. E.g. >> > htmlspecialchars() would not help you in many scenarios - e.g. it won't >> > protect you from XSS if you ever place user-controlled data in HTML >> > attributes. Having operator for each of the possible contexts does not >> > really looks feasible, and having it for only one of them and not the >> > others would be misleading people into thinking this operator is generic >> > and can be used in all contexts safely. >> > >> > -- >> > Stas Malyshev >> > smalys...@gmail.com >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: http://www.php.net/unsub.php >> > >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
