Re: Declare minimum PHP version required?

Hi Lester, On Wed, Feb 5, 2014 at 7:03 PM, Lester Caine <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? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net