Hi all,
On Mon, Feb 9, 2015 at 3:41 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> On Mon, Feb 9, 2015 at 2:12 PM, Daniel Lowrey <rdlow...@gmail.com> wrote:
>
>> First, let me say that I have voted against the current scalar types RFC.
>> Please do not let that color your evaluation of the rest of this message
>> ...
>>
>> I want to go on record (for the n-th time) as being unhappy about any
>> proposal that forces me to use php.ini. IMHO if it doesn't work with `$
>> php
>> -n` then it's not a solution, it's a hack. Yes, I understand that opcodes
>>
>
> "php -n" works (Well, we have data.timezone, though) with DbC. It should
> execute script in production mode.
>
>
>> can't be removed (perf, yay!) without knowing ahead of time from php.ini.
>> But the opcode removal difficulty should not be understood as a "well we
>> just have to do it this way," situation. Instead it ought to serve as a
>> warning sign that this is not the right answer. Type checking is not a
>> configuration-level issue; it is a language-level issue. Shoehorning it
>> into the .ini file is just another band-aid on a broken arm.
>>
>> We tend to hold new proposals to the litmus test, "can this be effectively
>> accomplished in userland already?" Well, yeah, in this case it really can.
>> Making assertions optionally throw isn't some great advancement:
>>
>> // I can do this now
>> if (!is_string($str) && DEBUG) throw new Exception("you bad coder bro");
>>
>
> In order to make robust and secure apps, functions/methods is better to
> have
> constraints. Type check is one of them. There are many people argue "This
> language is secure and robust because it has _static_ types".
>
>
> // I'm all for brevity but does this really need an RFC?
>> assert(is_string($str), "you bad coder bro");
>>
>> That's a pretty insignificant, surface-level improvement. Mostly I just
>> disagree with the assertion (see what I did there?) that this DbC RFC is
>> remotely the same as what the scalar types RFC is trying to accomplish.
>> And
>> it certainly doesn't have universal support.
>>
>
> DbC is not surface level change. It change application/code design a _lot_.
> In fact, DbC controversial what we have today and paradigm change.
>
> With modularized design, the more code is consolidated, the better code is.
> Therefore, parameter validity is checked deep into the code for example.
> Since
> these functions are rather simple basic functions that are used by many
> codes,
> the parameter validity is checked _many_ times over and over. This slows
> down
> execution.
>
> Solution? We should get rid of simple parameter validity checks from code
> written
> in basic functions. However, if we simply get rid of the check, we'll end
> up
> with too many bugs because caller forget about callee
> specifications(contracts).
>
> Here comes DbC, once we have contracts for pre/post conditions. We are
> safe from calling functions with invalid parameters during development, yet
> we have optimum performance for production since there is zero contract
> checks
> with production mode including opcode.
>
> My explanation is poor. So please research what is DbC more deeply.
> I think you'll like it once you understand the whole concept. Many
> languages
> have DbC support, in fact almost all languages, because DbC is extremely
> (It's extreme for me) useful to develop fast/secure apps.
>
I forgot to mention the most important.
DbC changes application/program design and the way of programming.
It changes PHP applications being more robust/secure and faster.
It changes PHP application development and testing, it will be more
efficient with DbC.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
