Just a thought, but I can't help thinking that "improved escape facilities
and syntax" are a mere patch for a more than superficial problem.
The problem of differentiating HTML strings, which to not require escaping,
from other string, which do, could actually be viewed as a deeper problem,
which is the inability to tell string types apart.
I mean, there are many different types of strings - text, HTML, URLs,
e-mail addresses, UUIDs, etc.
The surface problem is that user has to know whether she's dealing with a
text or HTML string. But you could view that as a symptom of the inability
to designate, at the source, what type of string you're providing.
For example, compare this:
class ProductView
{
/** @var string product name as plain text, remember to escape this
*/
public $product_name;
/** @var string product description as HTML, do not escape this */
public $description;
}
With something (completely ficticious) like, say:
typedef HTML extends string;
class ProductView
{
/** @var string product name */
public $product_name;
/** @var HTML product description */
public $description;
}
And a more intelligent escape function, like:
function html($str) {
return $str instanceof HTML ? $str : htmlspecialchars($str);
}
This removes one source of error - the user can now safely apply the html()
function to any string, without having to know if the string is just a
string or HTML. (yeah, I know about the $double_encode switch for
htmlspecialchars() but that's actually just another example of a
work-around to the same, deeper problem.)
A feature like this is more general-purpose, and potentially solves many
other related problems, such as recognizing the difference between ints or
UUIDs with different intent, e.g. being identifiers for different entities.
My main point is that the proposed feature attempts to fix a problem that
applies to one use-case - templates - whereas looking deeper and fixing
problems, or adding features that work across the entire language for many
use-cases, tends to add more value and, in the long run, less complexity.
Usually, a deeper, more general feature will enable users to create
solutions, rather than fixing each of their problems with surface
solutions, one at a time, until the language becomes a crazy colorful
cacophony of solutions, rather than tools to *create* solutions.
Just my perspective...
On Thu, Jul 28, 2016 at 11:48 AM, Rowan Collins <rowan.coll...@gmail.com>
wrote:
> On 28/07/2016 10:39, Thomas Bley wrote:
>
>> creating an e() function can be a BC break if people already have an e()
>> function in their code.
>> The name e is ambiguous to me, is it escape, error, encrypt?
>>
>> You are free to provide a better rfc, but having e() being optional will
>> also make security optional.
>>
>
> I wrote an entire e-mail setting out what I think should be the aims of
> the feature, and you've picked on a single sentence that said that an e()
> function would fulfil *most* of those aims. At no point did I say "an e()
> function is the perfect solution". You are attacking a straw man.
>
> I'm not going to get into a back and forth on what "optional" means,
> either. I've stated what I think is important, and will leave it there.
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
