> Did you know that you can alias namespaces, too? Yes
> You can always add more functions to a namespace even spread accross multiple > files Same problem: no autoloading. You would have to add require_one statements - which, as said, is not really possible with Composer packages... On Sun, Jun 19, 2016 at 9:53 AM, Niklas Keller <m...@kelunik.com> wrote: > > Rasmus Schultz <ras...@mindplay.dk> schrieb am Sa., 18. Juni 2016, 17:44: >> >> > 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. > > > Did you know that you can alias namespaces, too? > > <?php use My\Stuff\Escape as esc; ?> > <?=esc\html($str)?> > > You can always add more functions to a namespace even spread accross > multiple files. > >> 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 >> > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
