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 > >
