On 12.08.2016 at 10:19, Lester Caine wrote:
> On 11/08/16 23:17, Rowan Collins wrote:
>
>> You've mentioned a lot about flexibility, and that the feature could be
>> used in multiple styles, but some concrete examples of how *you* would
>> use it might help define what the feature needs to do (and not do).
>
> Currently my code has lots of checks for constraints and that is hard
> coded. Docblock helps to provide documentation and help in the IDE and
> there is no fundamental reason to change anything ... except. Small
> elements of the constraint process are being introduced into the
> process. You can now complain if the variable is not an integer but it
> does not remove the need to still check if the integer is valid. There
> have been various discussions on how the rules for that extra step could
> be added to PHP and in my book that has been there for years in the
> docblocks, but other layers are being proposed to add them, and Yasuo is
> now hiding them in his validate functions, so why not SIMPLY add a set
> of functions to variables to allow those rules to be freely available
> and managed on a variable by variable basis. The validate array function
> would then simply iterate over a cleanly defined set of variables? Or
> each variable can be managed in it's own right.
>
> 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);
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
