Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:94638 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 32764 invoked from network); 22 Jul 2016 18:41:27 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Jul 2016 18:41:27 -0000 Authentication-Results: pb1.pair.com smtp.mail=david.proweb@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=david.proweb@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.174 as permitted sender) X-PHP-List-Original-Sender: david.proweb@gmail.com X-Host-Fingerprint: 209.85.216.174 mail-qt0-f174.google.com Received: from [209.85.216.174] ([209.85.216.174:33885] helo=mail-qt0-f174.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 54/18-24343-6D862975 for ; Fri, 22 Jul 2016 14:41:26 -0400 Received: by mail-qt0-f174.google.com with SMTP id u25so66545444qtb.1 for ; Fri, 22 Jul 2016 11:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vtq2AAKfrYT0PDF/1M/toPZ6H20a0g3gOCDEDtCaKm4=; b=w9g16/MGTekgPMRUCSN+azaFvMRU9vg7NqhWVs/apdI7Tm3D9KsGRXCJAK2hBl+S96 utb6K/SBHJEY9QRj9UbM3PLqTnB9XN632Bqc/Cy6Nw5IkgNS5P/sQ9kAX1r4Pm439i/j 5NOfL0/KwBgL5Il4Jo3cQcvmwDW0Vv3CCUv5DftSEqmBOwUUvtb0tuCjzx6vtwaU1mZP CvjHfnCpUDJPfDrGEGLFG4t7w8fXwW03qwJWU2S/45u0fwvQ55qW4VVwY9Grt2COWh3i V1b/sjgujgb2woNB3KBDwfVvb4vAcDeww3Pj+/lhuOvZ7HovA+edWA+XjoL8cJvcYLU2 fdNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vtq2AAKfrYT0PDF/1M/toPZ6H20a0g3gOCDEDtCaKm4=; b=AJRRnMKAcJnAohevPHEGZ/sBAcB9wojPObKYnNRFlf7AYYBOXyQygKjGLFDi27Hhiz J2bTTrsnxK4NWJhbDJmfTnz6X7n0O0ZVdiNMRrnxJ+2K7mpD9Ycx8979YpkLvjk3HUI9 7AevuEax8arO9faa/ClTesMhOb2yLWb86WF4fhsUQ1j1mupKeRmhH9Eq2d1t7lG1Vom0 uxzfRfOeC5afr6Ko+2vFSGlPrDLVxg5xc3o9GyhzWhcktNKoFpiciSNBMohnXICVxWjD +I7p5YarWPCu3tveYvX+nj3H2Hldizgjcfs0BifGpmMC25SjB7z8HmuCGWHFsfMqTeC5 O4Hg== X-Gm-Message-State: AEkoousMXivH1LZui4HzNDcXesUdCZW0v4i3p/AhYwO/srqghzDbhUkPH9eJERIjs9JLyl2MeOMBBQgADaKquA== X-Received: by 10.200.45.8 with SMTP id n8mr8330108qta.57.1469212882975; Fri, 22 Jul 2016 11:41:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.45.67 with HTTP; Fri, 22 Jul 2016 11:41:03 -0700 (PDT) In-Reply-To: References: <8a39df34-4a23-c496-15f6-20a62d27fc59@gmail.com> Date: Fri, 22 Jul 2016 15:41:03 -0300 Message-ID: To: Michael Vostrikov Cc: PHP Internals Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] [RFC] New operator for context-dependent escaping From: david.proweb@gmail.com (David Rodrigues) The idea is good, but I think that is not pratical in general. --- First point: we should define each new identifier that could be used. It not make clear what this identifier does or even how it should works when a package redefines what it does. For instance: // file1.php set_escape_handler('e', 'html_entities_encode'); // file2.php set_escape_handler('e', 'my_own_encode'); // file3.php If file1.php includes file3.php, it should use first implementation. If file2.php does that, so will run the second implementation. I can't control from it come. If file1.php includes file2.php, what should happen? error? override? You can solve that by using the namespace, but then the implementation should be something like: But if you do that, is better you call it directly. --- Second point: can create a confusion with echo syntax, because it accepts comma separated arguments, like in --- Third point: the second argument is a string separated by comma, instead of separate each argument by it self. It is a string too, instead of an identifier like in --- Fourth point: this will create conflict to IDE, as joined string () is hard to identify each argument item, as splitted string () can confuse with a user string (if you get), as identifier is better, but it can conflict with const, but even if we ignore that, IDE will have problem by identify where you have defined it. Let's suppose that you have defined by a generic function, like: function create_escape($escape, $callback) { set_escape_handler($escape, function () use ($callback) { return doSomethingWith($callback) }); } create_scape('e', 'my_own_encode'); --- Fifth point: you can't use arguments on each escape to change the mean of what happen, so I need define each possibility (that could be a lot). For instance: imagine that I have a escape that does, on reality, a "clamp" that do a $value bet more than min, and less than max. It should receives two arguments (min and max) and optional one (inclusive). Currently I could do it like: . How you can do that on your case? --- Sixth point: current escape methods seems be more eficient and without create a new operator, like: But it can be improved with Sara suggestion with the pipe v2 (chain?) operator like e($$); ?> --- As conclusion, I think that if PHP create something like that, so is better PHP implements their own template engine system, turning this operation faster. But it can inflate PHP code with a template option that you don't like to use (for instance, I like Blade, but you can like Twig, another like PHP native template engine). I think that to some os problems above is create a exclusive scope to you apply your 'escapers', for instance: $escape = new SplEscaper; $escape->support('e', function () { ... }); $escape->require('myfile.php'); In this case, it'll require myfile.php and accept your escapers based on this instance.