Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82229
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.53 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAGa2bXa6ERO4RJO2ujWGVUMOJxz8NRfpkg_F69An_bp4Yt4=JQ@mail.gmail.com>
References: <CAH8MpnncAZ1UAaWyPaU8ZL7yDMXbas39X2sssK0yUONGTXxL6Q@mail.gmail.com>
 <CAGa2bXa6ERO4RJO2ujWGVUMOJxz8NRfpkg_F69An_bp4Yt4=JQ@mail.gmail.com>
Date: Mon, 9 Feb 2015 15:49:36 +0900
Message-ID: <CAGa2bXbPxXBWJgmVASur3Qm2dc6JTSbFZDvPwA90EJv3dfaQqg@mail.gmail.com>
To: Daniel Lowrey <rdlowrey@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c13054d04a7e050ea22e2f
Subject: Re: [PHP-DEV] Re: Design by Contract
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c13054d04a7e050ea22e2f
Content-Type: text/plain; charset=UTF-8

Hi all,

On Mon, Feb 9, 2015 at 3:41 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> On Mon, Feb 9, 2015 at 2:12 PM, Daniel Lowrey <rdlowrey@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
yohgaki@ohgaki.net

--001a11c13054d04a7e050ea22e2f--