Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95035
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.218 cause and error)
MIME-Version: 1.0
In-Reply-To: <c76f0716-4881-4aae-2fbd-f1af70fd6114@lsces.co.uk>
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>
Date: Thu, 11 Aug 2016 14:50:16 +0200
Message-ID: <CANUQDCjaXeJsCAjyE+q-UhXCFjexwRYWLKzMfwRQVDaEwVbLog@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7ba97a102e7bb40539cb356e
Subject: Re: [PHP-DEV] Simple variable handling.
From: me@kelunik.com (Niklas Keller)

--047d7ba97a102e7bb40539cb356e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2016-08-11 14:42 GMT+02:00 Lester Caine <lester@lsces.co.uk>:

> On 11/08/16 04:56, Micha=C5=82 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 caus=
e
> of
> > throwing much more unexpected exceptions during runtime?
> > Imagine you'll be passing such variable with constraint into some objec=
t
> > 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=3Dcontact
> 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
>
>

--047d7ba97a102e7bb40539cb356e--