Morning internals,
I really liked the original idea Dmitry had, with the D-ish syntax.
We could use require and return like:
function foo()
require(input-expr)
return(output-expr) {
/* ... */
}
to avoid adding more keywords.
I'd really appreciate seeing this as an option in the RFC.
Cheers
Joe
On Mon, Feb 9, 2015 at 8:44 AM, Dmitry Stogov <dmi...@zend.com> wrote:
> It's nothing wrong here. It's just a concept that cares about constraints
> definition more.
>
> So, DbC with asserts spread among the code is like OOP without classes.
>
> Thanks. Dmitry.
>
>
> On Mon, Feb 9, 2015 at 2:11 AM, Stanislav Malyshev <smalys...@gmail.com>
> wrote:
>
> > Hi!
> >
> > > Following our conversation, I tried to imagine how DbC should look like
> > in
> > > PHP from user perspective. Finally, I was influenced by the semantic
> > > proposed in D, and syntax proposed for Java. So, these are my initial
> > > thoughts:
> > >
> > > For php it may look like the following:
> > >
> > > function foo()
> > > requre(<input-assert-expression>)
> > > ensure(<output-assert-expression>)
> > > {
> > > ...
> > > }
> >
> > Why not do it simpler?
> >
> > function foo() {
> > // require
> > assert(<input-assert-expression>);
> > ...
> > // ensure
> > assert(<output-assert-expression>);
> > }
> >
> > I'm oversimplifying a bit, but in general, why we need more places to
> > have code in the function than the actual code of the function? It would
> > be harder to parse, to read, to maintain, to debug, to profile, etc. and
> > I'm not sure what exactly it provides that can't be done by plain
> > regular code inside the function.
> >
> > If we're concerned about the costs of assert, we could make special
> > provision in the compiler for zero-cost asserts. It doesn't require
> > moving code out of the function.
> > --
> > Stas Malyshev
> > smalys...@gmail.com
> >
>
