# Design by Contract

- Thread: https://externals.io/message/82223
- Original archive: https://news-web.php.net/php.internals/82223
- Started by Daniel Lowrey on 2015-02-09T05:12:10+00:00
- Messages: 6
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #82223 — Daniel Lowrey — 2015-02-09T05:12:10+00:00

URL: https://externals.io/message/82223#82223

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
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");

// 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.

---

## #82227 — Yasuo Ohgaki — 2015-02-09T06:41:03+00:00

URL: https://externals.io/message/82223#82227 · In reply to: #82223

Hi Daniel,



> 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.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #82229 — Yasuo Ohgaki — 2015-02-09T06:49:36+00:00

URL: https://externals.io/message/82223#82229 · In reply to: #82227

Hi all,



> 
>
> > […]
>
> "php -n" works (Well, we have data.timezone, though) with DbC. It should
> execute script in production mode.
>
>
> > […]
>
> 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?
> > […]
>
> 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

---

## #82322 — Stanislav Malyshev — 2015-02-10T00:24:20+00:00

URL: https://externals.io/message/82223#82322 · In reply to: #82227

Hi!

> constraints. Type check is one of them. There are many people argue "This
> language is secure and robust because it has _static_ types".

These people are wrong. Languages can't really be secure or robust, only
code implemented in these languages can, and we have witnessed many
examples of vulnerable code written in pretty much any widely used
language. Having strict typing may protect against some very basic
errors, but in well-designed and well-tested software such errors would
be rare, and in badly designed software type strictness would not save you.

> 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.

That assumes perfect test coverage in development, both code-wise and,
more importantly, data-wise. Which is impossible. While having assert
primitives that can be turned on and off looks like a useful concept to
me, I don't think it is some kind of magic solution that will change
everything.
-- 
Stas Malyshev
smalyshev@gmail.com

---

## #82323 — Yasuo Ohgaki — 2015-02-10T00:47:39+00:00

URL: https://externals.io/message/82223#82323 · In reply to: #82322

Hi Stas,

On Tue, Feb 10, 2015 at 9:24 AM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> > […]
>
> These people are wrong. Languages can't really be secure or robust, only
> code implemented in these languages can, and we have witnessed many
> examples of vulnerable code written in pretty much any widely used
> language. Having strict typing may protect against some very basic
> errors, but in well-designed and well-tested software such errors would
> be rare, and in badly designed software type strictness would not save you.
>

I agree partially. DbC encourages users to adopt secure coding best
practices.
Over all input/output must be controlled by programmers. This is secure
programming
best practice described in many security standards/guidelines. DbC
encourages it.
As you mentioned, well designed softwares do not have issues. DbC does not
solve issues directly, but encourage good design. As a result, program
becomes
more secure/robust.

If one have good design already, they don't have to adopt DbC for better
design.


>
> > […]
> yet
> > […]
>
> That assumes perfect test coverage in development, both code-wise and,
> more importantly, data-wise. Which is impossible. While having assert
> primitives that can be turned on and off looks like a useful concept to
> me, I don't think it is some kind of magic solution that will change
> everything.


Over all input/output controls are important for all application. This is
 "MUST
requirement" for DbC design to be successful.

With DbC, functions called in deep call chains will not check input
validity in
production mode. Therefore, DbC adopters must control over all inputs
at appropriate place (right after input was available to programmers) which
is security best practice.

Misuse of DbC increase risks in fact. DbC requires good design, too.
It's not an automatic solution as you describe.

Thank you for bring this topic.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #82329 — Dmitry Stogov — 2015-02-10T04:50:54+00:00

URL: https://externals.io/message/82223#82329 · In reply to: #82322

>
> Hi!
>
> > […]
"This
> > […]
>
> These people are wrong. Languages can't really be secure or robust, only
> code implemented in these languages can, and we have witnessed many
> examples of vulnerable code written in pretty much any widely used
> language. Having strict typing may protect against some very basic
> errors, but in well-designed and well-tested software such errors would
> be rare, and in badly designed software type strictness would not save
you.
>
> > […]
yet
> > […]
>
> That assumes perfect test coverage in development, both code-wise and,
> more importantly, data-wise. Which is impossible. While having assert
> primitives that can be turned on and off looks like a useful concept to
> me, I don't think it is some kind of magic solution that will change
> everything.

DbC is just an approach that may help to write safer programs. Of course,
it's just a tool and can't gurantee anything. It's also possible to write
safe code in assembler, but it's more difficult.

Thanks. Dmitry.

> --
> Stas Malyshev
> smalyshev@gmail.com