2016-08-11 14:42 GMT+02:00 Lester Caine <les...@lsces.co.uk>:
> On 11/08/16 04:56, Michał Brzuchalski wrote:
> > 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.
>
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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
