Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95077
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.230 cause and error)
To: internals@lists.php.net
References: <10fbcb03-5de8-4d9a-da1c-7e2bf77937cb@lsces.co.uk>
 <CAEYWF=4kkvmp8TCmRhdhzzM-sWpk+-sYE7u2eP1Jf3NkshFiJA@mail.gmail.com>
 <CABdc3WqYeoXoHL-E4adjoZTVr1bs1CHfRaDmoqtmpGW7yREmUA@mail.gmail.com>
 <c76f0716-4881-4aae-2fbd-f1af70fd6114@lsces.co.uk>
 <CANUQDCjaXeJsCAjyE+q-UhXCFjexwRYWLKzMfwRQVDaEwVbLog@mail.gmail.com>
 <d67a6ee8-4fbe-9583-3bac-d2e98298663f@lsces.co.uk>
 <5657afc7-7569-5fc4-4a5a-27ed786c4fa5@gmail.com>
 <0825c173-5cb4-7f65-cf34-b45ca30919a3@lsces.co.uk>
 <8646c3ad-b929-cb0b-bad4-52a0a7160d16@gmail.com>
 <11ce571b-964b-5a3e-9f2f-3f69a8bc20b4@lsces.co.uk>
 <7d9db8d5-ae7a-4123-14f4-f76fb6d764c5@gmail.com>
 <a25c0473-aa5f-7a1a-d1c9-0c8eebfd1188@lsces.co.uk>
 <24e9b0e6-f1f7-e6b7-0c6d-69e5ae1922cd@gmail.com>
Message-ID: <2e10971f-03f6-f484-e6d0-1f5706b3d5d7@lsces.co.uk>
Date: Fri, 12 Aug 2016 10:52:19 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2
MIME-Version: 1.0
In-Reply-To: <24e9b0e6-f1f7-e6b7-0c6d-69e5ae1922cd@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Simple variable handling.
From: lester@lsces.co.uk (Lester Caine)

On 12/08/16 09:54, Rowan Collins wrote:
> On 12/08/2016 09:19, Lester Caine wrote:
>> I'm thinking
>> $var->setConstraint()
>> $var->setEscape()
>> $var->setReadOnly()
>>
>> Rather than having to build 'reflections' classes to pull out data that
>> a simple $var->is_valid or echo $var will output a correctly escaped
>> piece of text.
> 
> Note that as discussed on the recent RFC thread, escape mechanisms are
> very much specific to the *destination* of the data not the *source*. So
> having "echo $foo" call "echo $foo->escape()" isn't going to work.
> 
> I guess you could have "echo $foo->forHTML()" with some kind of fallback
> that converts that to "echo htmlspecialchars($foo)" if nothing further
> is defined. Or "echo_html( $foo )" calling "$foo->forHTML()" internally
> if it's been defined against the variable. I haven't thought this
> through fully, just throwing ideas out there.

I struggled to see what problem adding more 'shortcut' tags was going to
solve. *I* have problems with third party sites returning data that may
or may not need 'un-escaping' and it's a little like trying to ensure I
get a UK rather than an American date. From the 'source' end it's almost
a 'this needs escaping' and you are right that where it is going forms
part of the 'escape' process, so the 'generic code' that handles echo
may benefit from expansion to echo_xxx to augment the process. Or just
like 'strict' mode we have 'js' mode and all output uses the appropriate
js rules rather than html?

I think the idea *I* am throwing out for discussion is a switch from
global_library($var, ... ) to $var->global_library( ... ) where $var is
now always an object without having every framework creating it's own
version of the wrapper?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk