On 12/08/16 10:42, Peter Lind wrote:
> On 12 August 2016 at 11:25, Lester Caine <les...@lsces.co.uk> wrote:
>
>> On 12/08/16 10:07, Christoph M. Becker 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.
>>> Actually, this is already possible; just use objects. E.g.
>>>
>>> class Container {
>>> function __construct() {}
>>> function setConstraint() {}
>>> function setEscape() {}
>>> function setReadOnly() {}
>>> function isValid() {}
>>> function __toString() {}
>>> }
>>> $var = new Container($some_value);
>>
>> This has been the problem all along. There is no overriding reason to
>> change what we already have, but ALL of the improvements currently being
>> discussed MAY be better handled with a return to the basic model of a
>> variable. If a variable is 'readonly' there is no need to worry about
>> each variable.
>>
>>
> Thanks for the ideas on this feature.
>
> A few thoughts.
> 1. The RFC for this isn't a change - it's an addition. If it gets accepted
> and implemented, you still would not have to change your code if you didn't
> want to.
I think that is the whole point ...
> 2. There are differing ways of using the language. Yours is not better -
> merely different. So I would think a relevant question is: can the RFC in
> point support your style of coding along with that of others. A critical
> point is throwing exceptions on invalid data, which might be hard to handle.
Exceptions get generated hen something unhandled happens. Simple example
'divide by zero' only happens if the divisor is zero. If the variable
used has a constraint of 'not zero' and has been validated then the
exception will not be raised. My style would validate the divisor and
only call the divide if it was going to work, others would allow the
divide to fail and MAY actually handle the exception ;)
> 3. Your assumption of secure intra-nets is questionable. Defense in depth
> is what one should strive for.
ACTUALLY that i why I've been looking for proper validation of data IN
PHP for the last 15 years. If the rules were easy to handle then
processing the the browser and cross checking the input array would be
consistent. It's just a shame that the browser end of things is an even
worse mess! html5 validation is somewhat incomplete as well?
> 4. I think your suggestions might conflate validation and sanitation -
> these are not the same and cannot be handled as one
That people try to inject malicious input via variables is a different
problem. Firebird database has always preferred parameter data so SQL
injections just don't work, but other stuff does need clearing when
input rather than simply relying on escaping unprocessed output. Again
it's programming sytle?
> That said, I generally think that built-in methods that accept Callables
> are a great way to go. It encourages reuse through modular composition -
> and could likely be a neater way around the throw exception/return error
> code issue. It's obviously doable from userland, but could probably be
> improved if implemented in the language.
It was the fact that Yasuo was adding these rules into his array
validation stuff that just grates so badly with what is actually needed ...
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
