Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94111
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.216 cause and error)
MIME-Version: 1.0
References: <CAEDdnaX_KbaZB=3WzFAp73E0dCxx5zuoqMbPbakMUGpHyRPJFg@mail.gmail.com>
 <b9318b90-f850-12a2-459d-8995220922df@gmail.com> <20160617202344.2868F1A80C02@dd1730.kasserver.com>
 <CAObuZdvZoACWE1bxz2PUMW+yXHxyEtXuYpPXL=6dEqrsakSNBQ@mail.gmail.com> <CADqTB_ijxN_ZVcAdLrpnejtYNO2x6Z1Q4PcnARCRE+etDuhF3w@mail.gmail.com>
In-Reply-To: <CADqTB_ijxN_ZVcAdLrpnejtYNO2x6Z1Q4PcnARCRE+etDuhF3w@mail.gmail.com>
Date: Sun, 19 Jun 2016 07:53:17 +0000
Message-ID: <CANUQDCjgSohsYWmkWOLfdL+9Jzio_uY-vnYVc4fzd6kmGaL46g@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>, Ryan Pallas <derokorian@gmail.com>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, Thomas Bley <mails@thomasbley.de>, 
	"internals@lists.php.net" <internals@lists.php.net>, michael.vostrikov@gmail.com
Content-Type: multipart/alternative; boundary=047d7b5d460415610505359ce2b9
Subject: Re: [PHP-DEV] New escaped output operator
From: me@kelunik.com (Niklas Keller)

--047d7b5d460415610505359ce2b9
Content-Type: text/plain; charset=UTF-8

Rasmus Schultz <rasmus@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 <derokorian@gmail.com>
> wrote:
> > On Fri, Jun 17, 2016 at 2:23 PM, Thomas Bley <mails@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
> >> > smalyshev@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
>
>

--047d7b5d460415610505359ce2b9--