Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94116
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.213.42 cause and error)
MIME-Version: 1.0
In-Reply-To: <CANUQDCjgSohsYWmkWOLfdL+9Jzio_uY-vnYVc4fzd6kmGaL46g@mail.gmail.com>
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> <CANUQDCjgSohsYWmkWOLfdL+9Jzio_uY-vnYVc4fzd6kmGaL46g@mail.gmail.com>
Date: Sun, 19 Jun 2016 11:34:42 +0200
Message-ID: <CADqTB_ih=WnH699EtKJJMbaL=5FnFsOwmgsutWxKC9ApX00TjQ@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: Ryan Pallas <derokorian@gmail.com>, Stanislav Malyshev <smalyshev@gmail.com>, 
	Thomas Bley <mails@thomasbley.de>, "internals@lists.php.net" <internals@lists.php.net>, 
	michael.vostrikov@gmail.com
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] New escaped output operator
From: rasmus@mindplay.dk (Rasmus Schultz)

> 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 <me@kelunik.com> wrote:
>
> 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
>>
>