# Simple variable handling.

- Thread: https://externals.io/message/95028
- Original archive: https://news-web.php.net/php.internals/95028
- Started by Lester Caine on 2016-08-10T20:07:05+00:00
- Messages: 62
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/95028.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #95028 — Lester Caine — 2016-08-10T20:07:05+00:00

URL: https://externals.io/message/95028#95028

People keep complaining that I do not contribute any proposals to
improve PHP, which to some extent s correct. Except the one thing that I
keep trying to get a handle on is tidying validating of the basic
variables that are the heart of PHP.

validate_var_array() is a case in point, since ALL it should do is
handle an array of simple variables for which we can define REAL
validation rules rather than just a very restricted 'type' rule.
Massaging the way the content of a variable is presented is another part
of the basic functions of handling a variable, and simply providing an
escape option which can be set as part of the variable rules set
eliminates the need for 'New operator (short tag) for context-dependent
escaping' and similar tangential matters. If we have a set of rules
wrapping a variable then everything else just follows on, and the SQL
domain model allows a group of variables to take an identical se of rules.

These are the sorts of things any decent user world library can and does
provide, but if the clock was rolled back prior to all the trouble
created by 'strict typing' and we started again with a more well defined
simple variable I'm sure that much of the conflict could have been
resolved by allowing full validation checks to control an error or
exception depending on the 'style' of PHP a programmer prefers.

If a function is going to return a variable and that variable has under
the hood a set of validation rules, then one can return an error if the
result is faulty. Or even allow a `NULL` return if a valid answer is not
available ... if that is the style of programming one prefers.
Exceptions handle unmanaged errors, while proper program flow handles
managed ones!

Wrap these intelligent variables inside a class and one can create more
powerful objects but ones which still use all the basic functionality.
Similarly an array of them can be asked to provide a simple 'yes/no' if
all of the variables pass their validation check, or an array of
elements which need processing.

-- 
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

---

## #95031 — Bishop Bettini — 2016-08-11T01:44:19+00:00

URL: https://externals.io/message/95028#95031 · In reply to: #95028

> People keep complaining that I do not contribute any proposals to
> improve PHP, which to some extent s correct. Except the one thing that I
> keep trying to get a handle on is tidying validating of the basic
> variables that are the heart of PHP.
>
> validate_var_array() is a case in point, since ALL it should do is
> handle an array of simple variables for which we can define REAL
> validation rules rather than just a very restricted 'type' rule.
> Massaging the way the content of a variable is presented is another part
> of the basic functions of handling a variable, and simply providing an
> escape option which can be set as part of the variable rules set
> eliminates the need for 'New operator (short tag) for context-dependent
> escaping' and similar tangential matters. If we have a set of rules
> wrapping a variable then everything else just follows on, and the SQL
> domain model allows a group of variables to take an identical se of rules.
>
> These are the sorts of things any decent user world library can and does
> provide, but if the clock was rolled back prior to all the trouble
> created by 'strict typing' and we started again with a more well defined
> simple variable I'm sure that much of the conflict could have been
> resolved by allowing full validation checks to control an error or
> exception depending on the 'style' of PHP a programmer prefers.
>
> If a function is going to return a variable and that variable has under
> the hood a set of validation rules, then one can return an error if the
> result is faulty. Or even allow a `NULL` return if a valid answer is not
> available ... if that is the style of programming one prefers.
> Exceptions handle unmanaged errors, while proper program flow handles
> managed ones!
>
> Wrap these intelligent variables inside a class and one can create more
> powerful objects but ones which still use all the basic functionality.
> Similarly an array of them can be asked to provide a simple 'yes/no' if
> all of the variables pass their validation check, or an array of
> elements which need processing.
>

Do you mean attaching a functional validator to a variable, something like
this hypothetical code? (Note the 3rd argument to settype):

// $_POST['age']  = 27;
// $_POST['name'] = 'Sugah Pop';

try {
    settype($_POST['age'],  'int',    'is_int');
    settype($_POST['name'], 'string', function ($name) { return
strlen($name) < 255; });
} catch (\TypeError $er) {
    die($er->getMessage());
}

// ... Later:

$_POST['name'] = str_repeat('a', 1024);
// Throws \TypeError: "Invalid value set into variable in demo.php on line
14"

Or same idea, but used as "smarter" formal argument validators:

function do_something($age, $name) {
    settype($age,  'int',    'is_int');
    settype($name, 'string', function ($name) { return strlen($name) < 255;
});
    // $age and $name now have persistent validator rules attached to them
    // write operations onto the variable will assert the truth of the
    // validator before assigning. Obviously, there is a run-time cost.
}

---

## #95032 — michal@brzuchalski.com — 2016-08-11T03:56:22+00:00

URL: https://externals.io/message/95028#95032 · In reply to: #95031

You want to stick such validation at runtime at any time with variable and
throwing \TypeError at any time constraint is broken - wouldn't it cause of
throwing much more unexpected exceptions during runtime?
Imagine you'll be passing such variable with constraint into some object
who operates on it and it should expect \TypeError at any time because you
newer know what sort of constraint and optional validation callback is
sticked to variable!

I think using constraints annotation style in OO would be much more
readable just like using constraint beans in Java
https://docs.oracle.com/cd/E19798-01/821-1841/gircz/index.html but that's
not the subject of discussion.

But that's only my humble opinion.

2016-08-11 3:44 GMT+02:00 Bishop Bettini <bishop@php.net>:

> 
>
> > […]
> rules.
> > […]
>
> Do you mean attaching a functional validator to a variable, something like
> this hypothetical code? (Note the 3rd argument to settype):
>
> // $_POST['age']  = 27;
> // $_POST['name'] = 'Sugah Pop';
>
> try {
>     settype($_POST['age'],  'int',    'is_int');
>     settype($_POST['name'], 'string', function ($name) { return
> strlen($name) < 255; });
> } catch (\TypeError $er) {
>     die($er->getMessage());
> }
>
> // ... Later:
>
> $_POST['name'] = str_repeat('a', 1024);
> // Throws \TypeError: "Invalid value set into variable in demo.php on line
> 14"
>
> Or same idea, but used as "smarter" formal argument validators:
>
> function do_something($age, $name) {
>     settype($age,  'int',    'is_int');
>     settype($name, 'string', function ($name) { return strlen($name) < 255;
> });
>     // $age and $name now have persistent validator rules attached to them
>     // write operations onto the variable will assert the truth of the
>     // validator before assigning. Obviously, there is a run-time cost.
> }
>



-- 
pozdrawiam
--
Michał Brzuchalski

---

## #95034 — Lester Caine — 2016-08-11T12:42:49+00:00

URL: https://externals.io/message/95028#95034 · In reply to: #95032

> You want to stick such validation at runtime at any time with variable and
> throwing \TypeError at any time constraint is broken - wouldn't it cause of
> throwing much more unexpected exceptions during runtime?
> Imagine you'll be passing such variable with constraint into some object
> who operates on it and it should expect \TypeError at any time because you
> newer know what sort of constraint and optional validation callback is
> sticked to variable!

Now this is where the fundamental difference in styles comes in.
PERSONALLY I would not be looking to throw exceptions at all. The whole
point of validation is to handle any validation error ... and it is an
error not an exception.

We have had the discussions on annotations and currently even historic
legacy systems still use docblock annotation to provide data that is not
handled in the core. The new 'styles' of adding this don't really
address making this area integral within the core, just as adding fancy
eyecandy to flag int or string does very little to the core validation
problems.

setannot( $age,  'number', range(1,120) ); // Fractional Years
or
$age->setannot( 'number', range(1,120) );

Both make perfect sense in my style of programming PHP, along with such
things as setaccess( 'public_readonly', 'no_write' );

This also comes in line with 'is_set' or 'is_valid'.
if ( !is_valid( $age ) { message( $age, 'no_valid' ); }
Rather than trying to capture some exception that was created out of line.

In my book if you want to produce compact optimised code then you should
be using C directly and the compiler optimizations. PHP needs a well
structured and compact runtime engine that handles simple objects such
as '$age' and every other variable using the ONE set of resident
optimised code, but it seems that everybody expects the runtime process
to duplicate copies of that code for every variable and then optimize
each to trim elements that are not needed for that particular use of the
variable? Why is it not simply a case that the table of variables simply
passes a pointer to the variable code to process an operation like
$age->setannot( 'number', range(1,120) ); at which point setannot( $age,
 'number', range(1,120) ); makes perfect sense since $age is simply
passed to the global library of code.

-- 
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

---

## #95035 — Niklas Keller — 2016-08-11T12:50:16+00:00

URL: https://externals.io/message/95028#95035 · In reply to: #95034

2016-08-11 14:42 GMT+02:00 Lester Caine <lester@lsces.co.uk>:

> 
> > […]
> and
> > […]
> of
> > […]
> you
> > […]
>
> Now this is where the fundamental difference in styles comes in.
> PERSONALLY I would not be looking to throw exceptions at all. The whole
> point of validation is to handle any validation error ... and it is an
> error not an exception.
>

If not by using exceptions, how would you handle them if you assign such
checks to variables and assign a wrong value?

Regards, Niklas


> We have had the discussions on annotations and currently even historic
> legacy systems still use docblock annotation to provide data that is not
> handled in the core. The new 'styles' of adding this don't really
> address making this area integral within the core, just as adding fancy
> eyecandy to flag int or string does very little to the core validation
> problems.
>
> setannot( $age,  'number', range(1,120) ); // Fractional Years
> or
> $age->setannot( 'number', range(1,120) );
>
> Both make perfect sense in my style of programming PHP, along with such
> things as setaccess( 'public_readonly', 'no_write' );
>
> This also comes in line with 'is_set' or 'is_valid'.
> if ( !is_valid( $age ) { message( $age, 'no_valid' ); }
> Rather than trying to capture some exception that was created out of line.
>
> In my book if you want to produce compact optimised code then you should
> be using C directly and the compiler optimizations. PHP needs a well
> structured and compact runtime engine that handles simple objects such
> as '$age' and every other variable using the ONE set of resident
> optimised code, but it seems that everybody expects the runtime process
> to duplicate copies of that code for every variable and then optimize
> each to trim elements that are not needed for that particular use of the
> variable? Why is it not simply a case that the table of variables simply
> passes a pointer to the variable code to process an operation like
> $age->setannot( 'number', range(1,120) ); at which point setannot( $age,
>  'number', range(1,120) ); makes perfect sense since $age is simply
> passed to the global library of code.
>
> --
> 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

---

## #95036 — Lester Caine — 2016-08-11T13:29:52+00:00

URL: https://externals.io/message/95028#95036 · In reply to: #95035

> > […]
> If not by using exceptions, how would you handle them if you assign such
> checks to variables and assign a wrong value?

This is where this 'strict' over 'weak' discussion starts. I have no
doubt that for some people a 'strict' switch would enable throwing
exceptions every time something that failed was actioned. While I'm
still in the camp where
if ( !$age->set( $result_set['age'] ) ) { // handle error }
else { // next step }
is a lot more readable than chaining everything together and building
some complex exception handler to process something which is much tidier
to handle in line ...

Much of the proposed style sugar only works for a completely different
style of working. I have yet to be convinced that re-factoring years of
code which naturally follows an in-line coding style would gain anything
from being reworked to the 'exception' style, but exceptions are being
added to the engine which may well be trigger by legacy styles and which
therefore have to be handled to keep code moving forward. Even something
as simple as reading each line of a CSV file and processing it until an
error is detected - such as end-of-file - requires a different mindset
if the errors throw you out of the data handling loop because of a
validation error.

Claiming that "You do not have to use the new style" misses the point
that often one has no control on where that new style impinges on legacy
code. Not least where third party code is an integral part of the
infrastructure. Even where PDO chaining has been used in third party
libraries, one invariably ends up pulling that apart to allow in-line
responses rather than remote exception handling. PDO is an area where
the correct handling of data validation would benefit from a clean built
in validation process. Rather than throwing some array handling
validator with an isolated set of rules at the problem post reading the
data.

-- 
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

---

## #95037 — Rowan Collins — 2016-08-11T13:51:18+00:00

URL: https://externals.io/message/95028#95037 · In reply to: #95036

> > […]


> if ( !$age->set( $result_set['age'] ) ) { // handle error }
> else { // next step }

So, cutting out the commentary about styles of coding, the answer to 
Niklas's question is "I would replace the assignment with a function or 
method that returned success based on validation result"?

To combine some of your examples:

// Set up the constraints:
$age->setannot( 'number', range(1,120) );

// Later:
$valid = $age->set( 'not a number' );
// or:
$age = $result_set['age'];
$valid = $age->is_valid();


This would result in $valid being false, but $age presumably still being 
the string 'not a number'? Or perhaps still being null, as though the 
assignment hadn't happened?

It seems like it would be more useful if the user didn't have to 
remember to call is_valid() on each variable before using it. That means 
having either the write operation, or subsequent read operations "fail" 
in some way.

$age_at_next_birthday = $age + 1; // reads from $age; is $age valid?

Throwing exceptions is a way of making operations like this "fail", 
rather than propogating the bad data to other parts of the program.

Does this look like the kind of thing you were imagining?

Regards,
-- 
Rowan Collins
[IMSoP]

---

## #95039 — Lester Caine — 2016-08-11T14:49:34+00:00

URL: https://externals.io/message/95028#95039 · In reply to: #95037

> 
> > […]
> 
> 
> > […]
> 
> So, cutting out the commentary about styles of coding, the answer to
> Niklas's question is "I would replace the assignment with a function or
> method that returned success based on validation result"?
> 
> To combine some of your examples:
> 
> // Set up the constraints:
> $age->setannot( 'number', range(1,120) );
> 
> // Later:
> $valid = $age->set( 'not a number' );
> // or:
> $age = $result_set['age'];
> $valid = $age->is_valid();
> 
> 
> This would result in $valid being false, but $age presumably still being
> the string 'not a number'? Or perhaps still being null, as though the
> assignment hadn't happened?
> 
> It seems like it would be more useful if the user didn't have to
> remember to call is_valid() on each variable before using it. That means
> having either the write operation, or subsequent read operations "fail"
> in some way.
> 
> $age_at_next_birthday = $age + 1; // reads from $age; is $age valid?
> 
> Throwing exceptions is a way of making operations like this "fail",
> rather than propogating the bad data to other parts of the program.
> 
> Does this look like the kind of thing you were imagining?

For an 'exception' model of PHP then I have no problem with actions
throwing exceptions, but from a 'work flow' model then replacing the
exceptions with checks simply works in my model. The question is not how
you flag an error, but rather when do you check for one. If the 'load'
function from a database record or the populate from a web form results
in $age not being valid one handles that situation based on the data
model. If you are propagating that data after validating has failed then
the program flow is wrong and adding some exception when you use the
duff data later does nothing to help?

-- 
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

---

## #95041 — Rowan Collins — 2016-08-11T15:14:08+00:00

URL: https://externals.io/message/95028#95041 · In reply to: #95039

> The question is not how
> you flag an error, but rather when do you check for one. If the 'load'
> function from a database record or the populate from a web form results
> in $age not being valid one handles that situation based on the data
> model. If you are propagating that data after validating has failed then
> the program flow is wrong and adding some exception when you use the
> duff data later does nothing to help?

Fair enough, so in summary, what you're looking for is a more 
comprehensive and/or user-friendly version of the filter_* functions?

That is, methods to:
- associate validation rules to a variable/array key/object property
- manually check whether the validation rules for one or several 
variables currently pass

But you are not particularly interested in language-level enforcement or 
tracking of whether and when these validation rules have been checked, 
because you want to insert the validation at specific points in the 
workflow.

Is that an accurate summary?

Regards,
-- 
Rowan Collins
[IMSoP]

---

## #95042 — michal.brzuchalski@gmail.com — 2016-08-11T15:22:32+00:00

URL: https://externals.io/message/95028#95042 · In reply to: #95041

Wgat about static analysis and IDE support? They probably can handle all
those sugarcandies because tgey are sticjed to variable but not with any
dynamic rules procedural style. Am I right?
11.08.2016 17:17 "Rowan Collins" <rowan.collins@gmail.com> napisał(a):

> 
>
> > […]
>
> Fair enough, so in summary, what you're looking for is a more
> comprehensive and/or user-friendly version of the filter_* functions?
>
> That is, methods to:
> - associate validation rules to a variable/array key/object property
> - manually check whether the validation rules for one or several variables
> currently pass
>
> But you are not particularly interested in language-level enforcement or
> tracking of whether and when these validation rules have been checked,
> because you want to insert the validation at specific points in the
> workflow.
>
> Is that an accurate summary?
>
> Regards,
> --
> Rowan Collins
> [IMSoP]

---

## #95043 — Rowan Collins — 2016-08-11T15:31:52+00:00

URL: https://externals.io/message/95028#95043 · In reply to: #95042

> Wgat about static analysis and IDE support? They probably can handle all
> those sugarcandies because tgey are sticjed to variable but not with any
> dynamic rules procedural style. Am I right?

Yep, that's a good point, add "machine-friendly" alongside 
"user-friendly" in my previous mail. :)

That is, if there is a comprehensive list of standard filters, IDEs and 
other tools can build them in and give useful hints. I guess it might 
also be possible to have an inspection of "validation rule assigned to 
variable appears to never be checked" in some cases.

In case it's not clear, I would welcome a smarter syntax to replace 
filter_* functions, as I think they're pretty unreadable as is.

Regards,
-- 
Rowan Collins
[IMSoP]

---

## #95046 — Lester Caine — 2016-08-11T20:19:20+00:00

URL: https://externals.io/message/95028#95046 · In reply to: #95041

> 
> > […]
> 
> Fair enough, so in summary, what you're looking for is a more
> comprehensive and/or user-friendly version of the filter_* functions?
> 
> That is, methods to:
> - associate validation rules to a variable/array key/object property
> - manually check whether the validation rules for one or several
> variables currently pass
> 
> But you are not particularly interested in language-level enforcement or
> tracking of whether and when these validation rules have been checked,
> because you want to insert the validation at specific points in the
> workflow.
> 
> Is that an accurate summary?

No ... add more than just validation rules. Include facilities such as
escape rules, display rules and variable specific material such as error
messages.

Just how the rules are enforced needs to be flexible and such things as
'required' will vary how the results are interpreted. I don't see that a
dynamic scripting language is improved by 'language-level enforcement'
when the bulk of the data IS flexible. It is the flexibility to include
or exclude checks as required and while a sub-set of code may work
better with a fixed set of rules defined at 'design time', just as much
code will consist of elements of the data set that will be optional or
variable. 'is_valid' on an object with a large set of variables is an
equally valid check and if each variable has the autonomy to return it's
state depending on other variables, then only the currently 'required'
variables need to be set and validated.

I AM interested in tracking the state of each variable but the validity
of it's state may depend on the specific state of other elements and a
failure to set a variable depends on the particular workflow of the
whole data set. So creating a workflow that allows different paths based
on the results of validation is a lot more flexible than simply calling
'validate' on a static array of variables?

But to keep the 'exception' camp happy, there is no reason that the
'strict' mode can't return exceptions while the 'weak' mode allows the
error to simply select an alternate path through the code.

-- 
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

---

## #95047 — Fleshgrinder — 2016-08-11T20:22:37+00:00

URL: https://externals.io/message/95028#95047 · In reply to: #95046

> No ... add more than just validation rules. Include facilities such as
> escape rules, display rules and variable specific material such as error
> messages.
> 
> Just how the rules are enforced needs to be flexible and such things as
> 'required' will vary how the results are interpreted. I don't see that a
> dynamic scripting language is improved by 'language-level enforcement'
> when the bulk of the data IS flexible. It is the flexibility to include
> or exclude checks as required and while a sub-set of code may work
> better with a fixed set of rules defined at 'design time', just as much
> code will consist of elements of the data set that will be optional or
> variable. 'is_valid' on an object with a large set of variables is an
> equally valid check and if each variable has the autonomy to return it's
> state depending on other variables, then only the currently 'required'
> variables need to be set and validated.
> 
> I AM interested in tracking the state of each variable but the validity
> of it's state may depend on the specific state of other elements and a
> failure to set a variable depends on the particular workflow of the
> whole data set. So creating a workflow that allows different paths based
> on the results of validation is a lot more flexible than simply calling
> 'validate' on a static array of variables?
> 
> But to keep the 'exception' camp happy, there is no reason that the
> 'strict' mode can't return exceptions while the 'weak' mode allows the
> error to simply select an alternate path through the code.
> 

What you are describing are classes. You can achieve all of that with them.

You are completely right btw. that exceptions should not be used during
validation and for flow control.

-- 
Richard "Fleshgrinder" Fussenegger

---

## #95048 — Lester Caine — 2016-08-11T20:44:04+00:00

URL: https://externals.io/message/95028#95048 · In reply to: #95047

> What you are describing are classes. You can achieve all of that with them.
> 
> You are completely right btw. that exceptions should not be used during
> validation and for flow control.

We have said all along that all of this can be done in classes, and yes
a variable is simply a small class. So why not create a generic variable
which has all the current hard coded functions as well as the rules to
carry out proper type management, secure escaping and machine readable
attributes to allow IDE's and other external code to standardise
handling them.

I'm more than happy with docblock attributes and others have proposed
alternate coding styles, but this IS simple if every variable is a well
defined object? Even a simple 'int' variable is more than just a C word.
It needs a much larger data packet with it's name and other settings,
and adding range checking expands that packet.

-- 
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

---

## #95050 — Rowan Collins — 2016-08-11T22:17:50+00:00

URL: https://externals.io/message/95028#95050 · In reply to: #95046

> No ... add more than just validation rules. Include facilities such as
> escape rules, display rules and variable specific material such as error
> messages.
>
> Just how the rules are enforced needs to be flexible and such things as
> 'required' will vary how the results are interpreted.

OK, so, again, you've mentioned plenty of the *why*, but what do you 
picture to be the *how*?

When would these various rules be applied? What might the code look like 
that relied on them?

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).

Regards,

-- 
Rowan Collins
[IMSoP]

---

## #95056 — Yasuo Ohgaki — 2016-08-12T02:27:47+00:00

URL: https://externals.io/message/95028#95056 · In reply to: #95028

Hi Lester,


> People keep complaining that I do not contribute any proposals to
> improve PHP, which to some extent s correct. Except the one thing that I
> keep trying to get a handle on is tidying validating of the basic
> variables that are the heart of PHP.
>
> validate_var_array() is a case in point, since ALL it should do is
> handle an array of simple variables for which we can define REAL
> validation rules rather than just a very restricted 'type' rule.
> Massaging the way the content of a variable is presented is another part
> of the basic functions of handling a variable, and simply providing an
> escape option which can be set as part of the variable rules set
> eliminates the need for 'New operator (short tag) for context-dependent
> escaping' and similar tangential matters. If we have a set of rules
> wrapping a variable then everything else just follows on, and the SQL
> domain model allows a group of variables to take an identical se of rules.
>
> These are the sorts of things any decent user world library can and does
> provide, but if the clock was rolled back prior to all the trouble
> created by 'strict typing' and we started again with a more well defined
> simple variable I'm sure that much of the conflict could have been
> resolved by allowing full validation checks to control an error or
> exception depending on the 'style' of PHP a programmer prefers.
>
> If a function is going to return a variable and that variable has under
> the hood a set of validation rules, then one can return an error if the
> result is faulty. Or even allow a `NULL` return if a valid answer is not
> available ... if that is the style of programming one prefers.
> Exceptions handle unmanaged errors, while proper program flow handles
> managed ones!
>
> Wrap these intelligent variables inside a class and one can create more
> powerful objects but ones which still use all the basic functionality.
> Similarly an array of them can be asked to provide a simple 'yes/no' if
> all of the variables pass their validation check, or an array of
> elements which need processing.

It sounds you are looking for autoboxing (or at least something similar)

https://wiki.php.net/rfc/autoboxing

I like this proposal, BTW. I'm not sure performance impact, though.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #95058 — Lester Caine — 2016-08-12T07:51:20+00:00

URL: https://externals.io/message/95028#95058 · In reply to: #95056

> It sounds you are looking for autoboxing (or at least something similar)
> 
> https://wiki.php.net/rfc/autoboxing

That is interesting, and is probably something I would expect to come
out in the wash with making a more intelligent variable. Except with
PHP's loose casting style I would expect 'array_sum' to simply take a
loose cast numeric version of every element. The tidy I think I am
looking for is that 'is_num' rules on each variable would control the
result. if any is 'null' the result is 'null' in normal SQL practice, or
switch strict mode on and the first 'is_num' that fails throws an exception.

> I like this proposal, BTW. I'm not sure performance impact, though.

What I am still missing is an understanding of just how the global
library of functions which act on a variable works internally with the
'list' of declared variables. People keep saying 'you just create a new
object' but in my book still that object is a fixed set of code - the
code library - and a variable set of data - the variable. Yes if the
variable now has a flag which says 'constrained' then there will be an
additional set of data with the constraints and as Rowan says, one has
to decide where that is processed and what you do with the result, but
the global code will check the 'constraint' element and see 'null' if it
has not been processed, valid, or some failure message such as 'over
limit'.

CURRENTLY the constraint element is handled in user code working with a
data set provided by docblock or other external storage means, SQL
schema for example. From a performance point of view I still prefer that
a lot of this is done in the IDE and that IS managing a lot of what we
are talking about and has been since the 2004 date of that rfc. But
almost every form I code on every website has a set of rules to
constrain each input and that data needs to be used in the code to
validate the variables being created, so isn't now the time to simply
add global functions that provide a single built in standard for
handling this problem?

From a practical point of view of cause, the validation of inputs may
well be done in the browser so that the constraints get passed TO some
html5 check, or javascript function. So having uploaded the form one
COULD simply tag a variable as valid? Or run the PHP validation as a
safety check. All of this is workflow and that workflow could include a
simple array function on the input array, but that still requires that
there are a set of constraint rules for each element of the array ...
applied to each variable ... so why can't we simply improve the variable?

-- 
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

---

## #95060 — Lester Caine — 2016-08-12T08:19:55+00:00

URL: https://externals.io/message/95028#95060 · In reply to: #95050

> 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.

-- 
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

---

## #95062 — michal@brzuchalski.com — 2016-08-12T08:36:20+00:00

URL: https://externals.io/message/95028#95062 · In reply to: #95058

2016-08-12 9:51 GMT+02:00 Lester Caine <lester@lsces.co.uk>:

> 
> > […]
>
> That is interesting, and is probably something I would expect to come
> out in the wash with making a more intelligent variable. Except with
> PHP's loose casting style I would expect 'array_sum' to simply take a
> loose cast numeric version of every element. The tidy I think I am
> looking for is that 'is_num' rules on each variable would control the
> result. if any is 'null' the result is 'null' in normal SQL practice, or
> switch strict mode on and the first 'is_num' that fails throws an
> exception.
>
> > […]
>
> What I am still missing is an understanding of just how the global
> library of functions which act on a variable works internally with the
> 'list' of declared variables. People keep saying 'you just create a new
> object' but in my book still that object is a fixed set of code - the
> code library - and a variable set of data - the variable. Yes if the
> variable now has a flag which says 'constrained' then there will be an
> additional set of data with the constraints and as Rowan says, one has
> to decide where that is processed and what you do with the result, but
> the global code will check the 'constraint' element and see 'null' if it
> has not been processed, valid, or some failure message such as 'over
> limit'.
>
> CURRENTLY the constraint element is handled in user code working with a
> data set provided by docblock or other external storage means, SQL
> schema for example. From a performance point of view I still prefer that
> a lot of this is done in the IDE and that IS managing a lot of what we
> are talking about and has been since the 2004 date of that rfc. But
> almost every form I code on every website has a set of rules to
> constrain each input and that data needs to be used in the code to
> validate the variables being created, so isn't now the time to simply
> add global functions that provide a single built in standard for
> handling this problem?
>
> From a practical point of view of cause, the validation of inputs may
> well be done in the browser so that the constraints get passed TO some
> html5 check, or javascript function. So having uploaded the form one
> COULD simply tag a variable as valid? Or run the PHP validation as a
> safety check. All of this is workflow and that workflow could include a
> simple array function on the input array, but that still requires that
> there are a set of constraint rules for each element of the array ...
> applied to each variable ... so why can't we simply improve the variable?
>

How does it differ from userland components/libraries like:

Symfony Form https://github.com/symfony/form
ZendFramework Form https://github.com/zendframework/zend-form
Phalcon Form https://docs.phalconphp.com/en/latest/reference/forms.html

and etc. They have additional functionalities to build form but validation
looks the same you want to acheive.
If most important thing of what you want to achieve is easy to use user
input validation there are plenty of lib which does that.
There you can put build in and own constraints, validate array and retrieve
valid data.
What is the reason such feature should be built in PHP language?


>
> --
> 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
>
> --
> 
> 
>
>


-- 
pozdrawiam
--
Michał Brzuchalski

---

## #95063 — michal@brzuchalski.com — 2016-08-12T08:43:52+00:00

URL: https://externals.io/message/95028#95063 · In reply to: #95060

2016-08-12 10:19 GMT+02:00 Lester Caine <lester@lsces.co.uk>:

> 
> > […]
>
> 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.
>

Because escaping can differ in context of usage? (html, css, js, xml, json.
etc.)
IMHO escaping pinned to variable is just bad idea.

In case of $var->setReadOnly() you will change variable behavior at runtime,
so it's behavior differs from one before that method run and after, it's
about consistency!

About ReadOnly I'm currently working on `immutable` feature proposal where
could be
possible to mark class and properties as immutable (ReadOnly after
initialisation)
so it could solve problem with ReadOnly ValueObjects and immutable
properties
which are simple primitives.


>
> --
> 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
>
> --
> 
> 
>
>


-- 
pozdrawiam
--
Michał Brzuchalski

---

## #95064 — Rowan Collins — 2016-08-12T08:54:35+00:00

URL: https://externals.io/message/95028#95064 · In reply to: #95060

> 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.

Regards,
-- 
Rowan Collins
[IMSoP]

---

## #95065 — Rowan Collins — 2016-08-12T08:58:48+00:00

URL: https://externals.io/message/95028#95065 · In reply to: #95058

> From a practical point of view of cause, the validation of inputs may
> well be done in the browser so that the constraints get passed TO some
> html5 check, or javascript function. So having uploaded the form one
> COULD simply tag a variable as valid?

Just a reminder to you and anyone else reading: NEVER TRUST USER INPUT. 
You can add all the JS in the world to your forms, but a user can always 
ignore that and craft their own input with whatever data they like in it.

---

## #95067 — Christoph M. Becker — 2016-08-12T09:07:06+00:00

URL: https://externals.io/message/95028#95067 · In reply to: #95060

> 
>
> > […]
> 
> 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

---

## #95070 — Lester Caine — 2016-08-12T09:21:12+00:00

URL: https://externals.io/message/95028#95070 · In reply to: #95065

> > […]
> 
> Just a reminder to you and anyone else reading: NEVER TRUST USER INPUT.
> You can add all the JS in the world to your forms, but a user can always
> ignore that and craft their own input with whatever data they like in it.

Many of my systems run on secure intra-nets and much of the 'safety
concerns' that have been brought up recently as 'essential' simply don't
apply. YES for web services that anybody has access to then 'NEVER TRUST
USER INPUT' is the rule, but for a simple local network only system then
one can trust that the browser is doing the right thing. It's one of the
reasons I've not been able to convert a number of sites since they don't
have a problem :(

-- 
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

---

## #95072 — Lester Caine — 2016-08-12T09:25:56+00:00

URL: https://externals.io/message/95028#95072 · In reply to: #95067

> > […]
> 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.

-- 
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

---

Next page: https://externals.io/message/95028.md?page=2