Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72265
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error)
Message-ID: <52F21D10.4050909@lsces.co.uk>
Date: Wed, 05 Feb 2014 11:14:24 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23
MIME-Version: 1.0
To: "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXYHP5D70bDBhbWzE7-B0s2kgk7DmAZdFhXkLqMJQqKV5g@mail.gmail.com> <52EF4BF8.60005@sugarcrm.com> <CAGa2bXacCxnmcAPZjh-YgTNocMjEpu_Uoc4npfNcKVM2WA2Tow@mail.gmail.com> <CAGa2bXZt7n8aqA=VrBKsqBzFiusGZP7aECPO-7xQher4+uVLWg@mail.gmail.com> <52F14C66.3030806@gmail.com> <CAH-PCH4+ULN2bVh=A2ZNvXmpYDqBPA3JrhhdrKb5zVH_sXucxg@mail.gmail.com> <52F15B62.1070006@gmail.com> <CAH-PCH4qXWJF_qN2ap0u+ufOMTah3VTR9t-BrV+9qkqD-KdixQ@mail.gmail.com> <CAGa2bXaj3Az2yYswgpS1yTFiYR+=j2tM-5y5paMrcjftx=X9pw@mail.gmail.com> <52F20C7C.3040803@lsces.co.uk> <CAGa2bXZq0XbUyu3oVd0+=x58xqpZbv8YiLuikSMGM3oY7x3O7A@mail.gmail.com>
In-Reply-To: <CAGa2bXZq0XbUyu3oVd0+=x58xqpZbv8YiLuikSMGM3oY7x3O7A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Declare minimum PHP version required?
From: lester@lsces.co.uk (Lester Caine)

Yasuo Ohgaki wrote:
> Hi Lester,
>
> On Wed, Feb 5, 2014 at 7:03 PM, Lester Caine <lester@lsces.co.uk
> <mailto:lester@lsces.co.uk>> wrote:
>
>     Yasuo Ohgaki wrote:
>
>         Yes. New assert() is as efficient as declare().
>         I cannot wait to use new assert()!
>
>
>     Yasuo
>     Please can you explain why you think this is so essential? The only place I
>     can think that I would use this I ALSO need to advise the users that there
>     is a problem. Adding 'assert' which apparently only has use while debugging
>     just seems wrong. Alright I add vd() and similar myself when debugging code
>     rather than using a 'debugger', but if I need to test something only at
>     debug time then I'll just add code and remove it when I have sorted the
>     problem. If it is a problem which will stop the code running, then it needs
>     a proper response in the workflow anyway.
>
>
> Since I'm a developer, I do not pay much attention once code hits production. (I
> do care errors a lot, though. I catch all errors/exceptions as a sign of fatal
> errors) Therefore, assert() is enough for me to alert users(developers) to
> notify something wrong during development.
>
> In contract, I think you pay much attention to production environment. I think
> it is very important for us (PHP internal developers) also. I guess you're
> dealing with a lot of end users and getting annoyed by PHP changes. Checking
> requirements at compile time would be valuable for you as you may configure PHP
> to display completely broken scripts for the environment. (i.e. Display compile
> error)
>
> For this use, declare() is the best solution. We might be better to think again
> for your use.
>
>     ADOdb and smarty both have switches to enable debugging which can be
>     switched on as required at runtime and I can't see any reason they would
>     switch to using assert instead?
>
>
> Assertion can be used to development time only checks so that programmers notice
> silly mistakes, passing invalid arguments for function, range check, type check,
> format check, pre/post condition check, etc. Even for ADOdb or Smarty
> developers, they have conditions that should be checked only when they are
> writing new code.
>
> I like DbC in D and other languages. For example, D supports "in" as
> precondition check, and "out" as post condition check.
>
> long square_root(long x)
>    in
>    {
>      assert(x >= 0);
>    }
>    out (result)
>    {
>      assert((result * result) <= x && (result+1) * (result+1) >= x);
>    }
>    body
>    {
>      return cast(long)std.math.sqrt(cast(real)x);
>    }
>
> With contract programming, caller has a responsibility to pass arguments that
> meets precondition contract and callee has responsibility returns a result that
> meets post condition contract. If whole program is made this way, callee does
> not have to check pre/post condition at all as long as input for program is
> validated
> strictly. With contract programming, lower level functions does not have to
> check arguments under production environment at all, thus program runs much
> faster than traditional design yet it achieves robustness. (in theory. We're
> better to leave some checks for fatal error especially for security related matter)
>
> Assertion that does not have run time overheads at all is very cool thing for
> PHP developers to write robust and fast applications, especially for developers
> who prefer micro frameworks. (Missing pace for PHP is pre/post condition check,
> but it's much better than before and it can work round. Comprehensive frameworks
> have contract via annotation, etc at user land.)
>
> I agree that assert() may not help you much from your users asking "I got blank
> screen!", but it helps developers a lot. It also may help you if your user can
> change INI setting to see what's wrong.
>
> Does this answer your question?

Yes and no ... Thank you very much for taking the time!

It does explain nicely what is being talked about, and I can now understand 
where you are coming from. I have some 20 years of programming experience 
predating using PHP, and switched to PHP mainly because it did NOT have the same 
straight jacket that c/c++ imposes. My customers are simply using PHP 
applications to do a job, and they have no interest in many of the things 
currently being pushed forward as 'essential' here. I think reading the above 
that you will understand that? They just want their applications to continue to 
work ...

-- 
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