Hi Yasuo,
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()
req
I've been reading and I discovered a concept called Design By
Contract. I've not seen any particular libraries to aid in this
particular development design process, but I was wondering if you
folks had, or if there were plans to consider providing for this
functionality within PHP. (A longshot, I k
Am 05.02.2015 12:14 schrieb "Dmitry Stogov" :
>
> For php it may look like the following:
>
> function foo()
> require()
> ensure()
> {
> ...
> }
>
> It would require only one new reserved word "ensure".
How would one access the function return value in the
output-assert-expression?
And
On Thu, Feb 5, 2015 at 2:38 PM, Patrick Schaaf wrote:
> Am 05.02.2015 12:14 schrieb "Dmitry Stogov" :
> >
> > For php it may look like the following:
> >
> > function foo()
> > require()
> > ensure()
> > {
> > ...
> > }
> >
> > It would require only one new reserved word "ensure".
>
> H
Hi Dimitry
> -Ursprüngliche Nachricht-
> Von: Dmitry Stogov [mailto:dmi...@zend.com]
> Gesendet: Donnerstag, 5. Februar 2015 12:14
> An: Yasuo Ohgaki; PHP Internals
> Betreff: [PHP-DEV] Design by Contract
>
> Hi Yasuo,
>
> Following our conversation, I trie
12:14
> > An: Yasuo Ohgaki; PHP Internals
> > Betreff: [PHP-DEV] Design by Contract
> >
> > Hi Yasuo,
> >
> > Following our conversation, I tried to imagine how DbC should look like
> in PHP from user perspective. Finally, I was
> > influenced b
On Thursday 05 February 2015 15:14:04 Dmitry Stogov wrote:
>
> function foo()
> requre()
> ensure()
> {
> ...
> }
>
> It would require only one new reserved word "ensure".
Regarding syntax This could be another place where the irrationally-
dreaded declare would make sense:
functio
Hello, internals!
>From my point of view, contracts should not affect execution of source code
in production env, or can be enabled partially. I have implemented DbC
paradigm on top of the AOP layer, so each contract can be defined via
annotation and looks pretty nice, for example :
use PhpDeal\A
this way we would able to use in constraints any statements.
The require/ensure syntax was limited to expressions (to limit users in
making side effects).
May be we may reuse delare() a bit differently.
function foo() {
declare(pre=)
declare(post=)
{
}
However. I like require/ensure mor
So, is it possible to use annotations for defining such metadata on
engine-level? This will be a good way to do this and to define custom
handlers via AST hooks, that can be able to patch method definition node
with concrete opcodes.
2015-02-05 15:24 GMT+03:00 Alexander Lisachenko :
> Hello, inte
Hi Alexander,
Defining contracts through doc-comments is also possible, but this way is
not native.
On the other hand, if you already have this implemented, we may just reuse
it.
Thanks. Dmitry.
On Thu, Feb 5, 2015 at 3:24 PM, Alexander Lisachenko <
lisachenko...@gmail.com> wrote:
> Hello, inte
For now, we don't have any mechanism for annotations or attributes except
for doc-comments.
Thanks. Dmitry.
On Thu, Feb 5, 2015 at 3:27 PM, Alexander Lisachenko <
lisachenko...@gmail.com> wrote:
> So, is it possible to use annotations for defining such metadata on
> engine-level? This will be a
2015-02-05 15:32 GMT+03:00 Dmitry Stogov :
> Hi Alexander,
>
> Defining contracts through doc-comments is also possible, but this way is
> not native.
> On the other hand, if you already have this implemented, we may just reuse
> it.
>
Thanks, Dmitry! This would be a really nice feature on engin
At this moment, I don't have any plans related to implementation of
hook-able compiler.
However the first step was already done, introducing "zend_ast_process"
callback.
In general it's should be possible to provide PHP API to manipulate with
AST and write compiler extensions in PHP.
Looks promisin
Hi Dmitry,
> De : Dmitry Stogov [mailto:dmi...@zend.com]
>
> 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:
Please
2015-02-05 16:07 GMT+03:00 Dmitry Stogov :
> In general it's should be possible to provide PHP API to manipulate with
> AST and write compiler extensions in PHP.
> Looks promising.. :)
> Anyway, If you are interested - start working on it.
Actually, it's almost done by Nikita Popov: https://git
Yeah, this may work.
The only problem, that it looks not native and defines additional language
for constraints.
I don't talk it's wrong. Both approaches may make sense, but of course, we
have to select one.
Thanks. Dmitry.
On Thu, Feb 5, 2015 at 4:19 PM, François Laupretre
wrote:
> Hi Dmitry,
php-ast is not almost the same, but it may be extended.
Thanks. Dmitry.
On Thu, Feb 5, 2015 at 4:34 PM, Alexander Lisachenko <
lisachenko...@gmail.com> wrote:
>
> 2015-02-05 16:07 GMT+03:00 Dmitry Stogov :
>
>> In general it's should be possible to provide PHP API to manipulate with
>> AST and w
De : Dmitry Stogov [mailto:dmi...@zend.com]
> Yeah, this may work.
> The only problem, that it looks not native and defines additional language
> for constraints.
> I don't talk it's wrong. Both approaches may make sense, but of course, we
> have to select one.
Yes, it makes phpdoc more tied t
Hi Internal :-),
I just would like to point out some stuff.
tl;dr: Contracts can be used to validate code (Design-by-Contract) or
generate test data to validate code (Contract-based Testing). There are
plenty of contract languages in the wild, each one addresses a specific
problem (object, s
On Feb 5, 2015 8:54 PM, "François Laupretre" wrote:
>
> De : Dmitry Stogov [mailto:dmi...@zend.com]
>
> > Yeah, this may work.
> > The only problem, that it looks not native and defines additional
language for constraints.
> > I don't talk it's wrong. Both approaches may make sense, but of course,
Hi Patrick,
On Thu, Feb 5, 2015 at 9:13 PM, Patrick Schaaf wrote:
> On Thursday 05 February 2015 15:14:04 Dmitry Stogov wrote:
> >
> > function foo()
> > requre()
> > ensure()
> > {
> > ...
> > }
> >
> > It would require only one new reserved word "ensure".
>
> Regarding syntax Thi
Hi all,
On Fri, Feb 6, 2015 at 12:00 AM, Pierre Joye wrote:
> On Feb 5, 2015 8:54 PM, "François Laupretre" wrote:
> >
> > De : Dmitry Stogov [mailto:dmi...@zend.com]
> >
> > > Yeah, this may work.
> > > The only problem, that it looks not native and defines additional
> language for constraints
De : Pierre Joye [mailto:pierre@gmail.com]
>> Yes, it makes phpdoc more tied to the engine but is it a problem ?
>
> And here I have to jump in and say: don't.
> And remind about one of the exact purposes of annotations.
Sorry, I am not sure I understand.
If you're talking about the link be
Hi Ivan,
On Thu, Feb 5, 2015 at 11:25 PM, Ivan Enderlin @ Hoa <
ivan.ender...@hoa-project.net> wrote:
> I just would like to point out some stuff.
>
>
> tl;dr: Contracts can be used to validate code (Design-by-Contract) or
> generate test data to validate code (Contract-based Testing). There are
> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
> We don't have to integrate DbC into phpdoc. phpdoc may have integration of
> new DbC syntax.
> I think it's helpful even if phpdoc copies post/pre condition as document.
>
> There are too many possibility for DbC sy
Hi Francois,
On Fri, Feb 6, 2015 at 1:11 AM, François Laupretre
wrote:
> > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
> Ohgaki
>
> > We don't have to integrate DbC into phpdoc. phpdoc may have integration
> of new DbC syntax.
> > I think it's helpful even if phpdoc cop
phpdoc is annotation as well, but to split it into specific attributes we
have to write specialized parsers.
Other languages support annotation or attributes that may be used more
easily.
http://docs.hhvm.com/manual/en/hack.attributes.php
Thanks. Dmitry.
On Thu, Feb 5, 2015 at 6:40 PM, François
This is just a brainstorming, and we are not going to provide a working
solution tomorrow :)
You have enough time :)
I don't like phpdoc approach because we have to define, parse and compile
new syntax for constraints.
Would constraint be able to call other functions? include external php
files? e
De : Dmitry Stogov [mailto:dmi...@zend.com]
>
> I don't like phpdoc approach because we have to define, parse and compile new
> syntax for constraints.
> Would constraint be able to call other functions? include external php files?
> etc?
There are 2 sort of constraints :
- declared types with
Hi Francois,
On Fri, Feb 6, 2015 at 1:18 AM, Yasuo Ohgaki wrote:
>
> On Fri, Feb 6, 2015 at 1:11 AM, François Laupretre
> wrote:
>
>> > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
>> Ohgaki
>>
>> > We don't have to integrate DbC into phpdoc. phpdoc may have integration
On Fri, Feb 6, 2015 at 2:54 AM, Yasuo Ohgaki wrote:
> Is there is syntax error or assertion error. Error messages look like
I mean
If there is syntax error...
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Fri, Feb 6, 2015 at 2:54 AM, Yasuo Ohgaki wrote:
> __invariant()
Oops
__invariant_before_foo()
__invariant_after_foo()
There are other bad english. I should spend more time to check. Sorry.
--
Yasuo Ohgaki
yohg...@ohgaki.net
If we allow any statements in require/ensure, then we should use {} instead
of()
function foo($a, $b)
reuire {
...
}
ensure($ret) {
...
}
{
}
my idea was to restrict constraint code to expression.
in this case () would be enough.
it should be possible to use few con
Hi Dmitry,
On Fri, Feb 6, 2015 at 3:58 AM, Dmitry Stogov wrote:
> I don't think we should chose "right" approach right now.
> It's better to collect few possible solutions e.g. statements,
> expressions, doc-comments, attributes...
> then describe their pros and cons to select the best one
>
I
On Thu, Feb 5, 2015 at 11:36 PM, Dmitry Stogov wrote:
> phpdoc is annotation as well, but to split it into specific attributes we
> have to write specialized parsers.
> Other languages support annotation or attributes that may be used more
> easily.
>
> http://docs.hhvm.com/manual/en/hack.attribut
On Thu, Feb 5, 2015 at 11:44 PM, Dmitry Stogov wrote:
> This is just a brainstorming, and we are not going to provide a working
> solution tomorrow :)
> You have enough time :)
>
> I don't like phpdoc approach because we have to define, parse and compile
> new syntax for constraints.
> Would const
Hi all,
I already said before and I'm happy to say it again...
Whenever you feel ready to get true, complete Annotations into core, just
tell me and I'll be ready to work on previously suggested Annotations in
sync with current internals.
Cheers,
On Thu, Feb 5, 2015 at 11:00 PM, Pierre Joye wro
On Fri, Feb 6, 2015 at 11:08 AM, guilhermebla...@gmail.com
wrote:
> Hi all,
>
> I already said before and I'm happy to say it again...
> Whenever you feel ready to get true, complete Annotations into core, just
> tell me and I'll be ready to work on previously suggested Annotations in
> sync with
Hi Pierre,
Sorry, but you don't. Proposing a simple syntax is the same as not
proposing it.
We can do whatever syntax is proposed, but we need to discuss on how to
handle inheritance, overriding, etc.
None ever discussed that. 2010's patch handled all that nicely. I do
remember however Dmitry had
On Fri, Feb 6, 2015 at 11:14 AM, guilhermebla...@gmail.com
wrote:
> Hi Pierre,
>
> Sorry, but you don't. Proposing a simple syntax is the same as not proposing
> it.
> We can do whatever syntax is proposed, but we need to discuss on how to
> handle inheritance, overriding, etc.
> None ever discuss
> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
>
> Thank you for your time. It's based on annotation approach. This kind of
> implementation requires a lot of work...
I have an idea of a way to do it with limited work. Most important, everything
would be in an ext
On 05/02/15 17:09, Yasuo Ohgaki wrote:
Hi Ivan,
Hi Yasuo :-),
On Thu, Feb 5, 2015 at 11:25 PM, Ivan Enderlin @ Hoa
mailto:ivan.ender...@hoa-project.net>>
wrote:
I just would like to point out some stuff.
tl;dr: Contracts can be used to validate code (Design-by-Contract)
or ge
On 06/02/15 05:00, Pierre Joye wrote:
On Thu, Feb 5, 2015 at 11:36 PM, Dmitry Stogov wrote:
phpdoc is annotation as well, but to split it into specific attributes we
have to write specialized parsers.
Other languages support annotation or attributes that may be used more
easily.
http://docs.h
Hi Ivan,
On Fri, Feb 6, 2015 at 4:44 PM, Ivan Enderlin @ Hoa <
ivan.ender...@hoa-project.net> wrote:
>
>
>
> On Thu, Feb 5, 2015 at 11:25 PM, Ivan Enderlin @ Hoa <
> ivan.ender...@hoa-project.net> wrote:
>
>> I just would like to point out some stuff.
>>
>>
>> tl;dr: Contracts can be used to val
On Fri, Feb 6, 2015 at 2:01 AM, Yasuo Ohgaki wrote:
> Hi Dmitry,
>
> On Fri, Feb 6, 2015 at 3:58 AM, Dmitry Stogov wrote:
>
>> I don't think we should chose "right" approach right now.
>> It's better to collect few possible solutions e.g. statements,
>> expressions, doc-comments, attributes...
>
annotations might be useful for DbC, but I doubt if they are more readable.
< 0)>>
< 0)>>
< 0)>>
function foo ($a, $b) {
return $a + $b;
}
Also, to use them, we will have to develop them first (not a trivial task
as well), but may be this is a right road.
Thanks. Dmitry.
On Fri, Feb 6, 20
Hi,
do you have a link to old proposal and/or implementation?
Thanks. Dmitry.
On Fri, Feb 6, 2015 at 7:08 AM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> Hi all,
>
> I already said before and I'm happy to say it again...
> Whenever you feel ready to get true, complete Annota
> De : Ivan Enderlin @ Hoa [mailto:ivan.ender...@hoa-project.net]
> > Exactly, phpdoc is used as annotation (or comments with some similar
> > syntax) but is definitively not aimed to be annotations.
> Exact. Annotations !== comments. Because PHP has no annotation system,
> we used to use comments
Just a thought: may be we can reuse part of PHP syntax and ask standard PHP
parser to do the work and provide AST.
<>
<>
I don't know if it's possible to implement...
Thanks. Dmitry.
On Fri, Feb 6, 2015 at 7:04 AM, Pierre Joye wrote:
> On Thu, Feb 5, 2015 at 11:44 PM, Dmitry Stogov wrote:
>
Hi Yasuo,
> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
> Do you think of any negative impact on PHP if we implement D like
> in{}/out{} which allow any PHP syntax?
Can you please give your opinion about the BC break a D-like syntax would
introduce ? It is import
Hi Francois,
On Fri, Feb 6, 2015 at 6:55 PM, François Laupretre
wrote:
> > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
> Ohgaki
> > Do you think of any negative impact on PHP if we implement D like
> > in{}/out{} which allow any PHP syntax?
>
> Can you please give your
this is not going to be a BC break, this is going to be a Forward
Compatibility break, that won't allow PHP code that use this feature work
on PHP5.
Scalar type hints and attributes are also going to introduce such breaks.
On the other hand if we keep constraints in phpdoc, PHP core shouldn't car
Hi Francois,
On Fri, Feb 6, 2015 at 7:34 PM, Yasuo Ohgaki wrote:
> I can understand motivation to write script runs in older release.
> It's nice, I agree.
>
> Personally, backward compatibility is not too important.
> PHP5 is dead by PHP 7.2 release... This is the reason why.
> It's only 3 year
> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
> Personally, backward compatibility is not too important.
> PHP5 is dead by PHP 7.2 release... This is the reason why.
> It's only 3 years later, only 2 years later after PHP 7.0 release.
That's where we disagree, as
On 06/02/15 15:17, François Laupretre wrote:
> You probably didn't live the PHP 4/5 migration
Now, this seems to become a habit.
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Dmitry,
Last time we discussed was this one: https://wiki.php.net/rfc/annotations
The ideal one was the version before:
https://wiki.php.net/rfc/annotations?rev=1300089833
To have this in core, we need to step back and re-evaluate how we could
achieve 80% minimum. My original proposal was tryi
I see your point, and, of course, it makes sense, but it also means that no
new PHP7 features might not be used in these frameworks and libraries for a
long time. Should we stop add new features in major releases?
As I said, according to DbC, I'm not sure if it should be defined on
language level.
in my opinion, RFC looks reasonable.
can you remember main arguments against it.
why it was declined?
For PHP7, it may be possible to change RFC to accept any PHP expression as
annotation value.
Then this expression may be captured as AST or evaluated to constant.
Thanks. Dmitry.
On Fri, Feb 6
Dmitry,
Doc comments are terrible. I really want you to spend some time looking at
what we had to do inside of Doctrine Annotations to make it work. We have
to token_get_all() the file to be processed and track for "use"s to allow
importing inside of doc blocks. We also had to build a top-down rec
Hi Dmitry,
Actually the RFC was approved by 1 or 2 votes more than needed, but the
overall response from core maintainers was that it was overly complex,
adding features the language did not support until that point (named
parameters, short array syntax as examples), it was broken with the
propose
On Fri, Feb 6, 2015 at 6:12 PM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> Dmitry,
>
> Doc comments are terrible. I really want you to spend some time looking at
> what we had to do inside of Doctrine Annotations to make it work. We have
> to token_get_all() the file to be pro
I think the original proposal is more consistent then the simple one.
Most probably, it just came not in right time.
In case @internals really like annotations and we came to consensus how it
should look like, I may take care about efficient implementation.
Thanks. Dmitry.
On Fri, Feb 6, 2015 at
> On the other hand you have a working solution.
> You won't be able to use annotations for PHP5 projects anyway.
> Except, if we put them into comments or doc-comments.
>
> /**[Attribute(Value)]*/
Why not /**@ Attribute Value */ or /**@ Attribute(Value) */? No []
required and @ looks more famili
Hi Dmitry,
So, can we start drafting out some things?
Simple questions would help everybody to get this moving forward.
I'll compile a simple list of questions to answer that would drive the
direction on how it would be implemented.
Please ignore the formatting on HOW they are defined. Tokens can
I may give my opinion, but it's going to be only mine.
May be it's better to write all these question in RFC and make everyone to
expose their opinion.
It shouldn't be a final voting, just a survey that would help us make a
decisions, where to go.
don't dive into implementation details, use cases,
Hi Dmitri,
Yes, unfortunately, PHP features not compatible with the PHP 5 interpreter will
be harder to adopt for most developers, even if they are not technically BC
breaks.
I agree with your POV, as I now think that it shouldn't be included in the
core, provided we have the needed hooks. I
Hi,
> De : guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com]
> Envoyé : vendredi 6 février 2015 19:22
> À : Dennis Birkholz
> Cc : PHP internals
> Objet : Re: [PHP-DEV] Design by Contract
>
> Hi Dmitry,
>
> So, can we start drafting out some things?
&g
On Fri, Feb 6, 2015 at 9:17 PM, François Laupretre wrote:
>> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
>
>> Personally, backward compatibility is not too important.
>> PHP5 is dead by PHP 7.2 release... This is the reason why.
>> It's only 3 years later, only 2 y
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
Hi Stas,
On Mon, Feb 9, 2015 at 8:11 AM, Stanislav Malyshev
wrote:
> > 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
>
Hi Yasuo,
Design by Contract could be used at the top of Annotation if (and only if)
it also had support for Interceptors. Since it could potentially be a
nightmare for PHP, I don't think it's time to propose something at the top
of another thing that is still far from being reality.
It would foll
Hi Guilherme,
On Mon, Feb 9, 2015 at 11:58 AM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> Design by Contract could be used at the top of Annotation if (and only if)
> it also had support for Interceptors. Since it could potentially be a
> nightmare for PHP, I don't think it's
Hi Yasuo,
Class invariants could be done as this example:
class Foo {
private function isValidState() {
// Checks class's state and returns boolean
}
public function doSomething($args) {
// Some complex operation over Foo instance using $args
// then...
Hi Guilherme,
On Mon, Feb 9, 2015 at 1:44 PM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> Class invariants could be done as this example:
>
> class Foo {
> private function isValidState() {
> // Checks class's state and returns boolean
> }
>
> public functi
>
> There are a lot of researches in this field. PHP has a great opportunity to
> not close the doors by forcing a language. I suggest you to offer an API to
> hook on the runtime and “control” it, like AOP does. It will open the doors
> to so many interesting contributions!
>
Hello,
after readin
Hi,
I'll try to answer to all the emails at once.
Personally, I like the D approach more, but doc-comment proposal has its
advantages as well.
The problem that doc-comment solution is external to PHP core.
In my opinion, it should be implemented as a separate preprocessor that
reads doc-comments
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
wrote:
> Hi!
>
> > Following our conversation, I tried to imagi
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
On 06/02/15 09:44, Yasuo Ohgaki wrote:
Hi Ivan,
Hi Yasuo :-),
On Fri, Feb 6, 2015 at 4:44 PM, Ivan Enderlin @ Hoa
mailto:ivan.ender...@hoa-project.net>>
wrote:
On Thu, Feb 5, 2015 at 11:25 PM, Ivan Enderlin @ Hoa
mailto:ivan.ender...@hoa-project.net>> wrote:
I just wou
Usage of "return" is a good idea.
The more heads the better result :)
Thanks. Dmitry.
On Mon, Feb 9, 2015 at 11:48 AM, Joe Watkins wrote:
> Morning internals,
>
> I really liked the original idea Dmitry had, with the D-ish syntax.
>
>We could use require and return like:
>
> functio
Can you suggest what exactly should be done?
Thanks. Dmitry.
On Mon, Feb 9, 2015 at 11:16 AM, Pavel Kouřil wrote:
> >
> > There are a lot of researches in this field. PHP has a great opportunity
> to
> > not close the doors by forcing a language. I suggest you to offer an API
> to
> > hook on t
Hi Dmitry and Joe,
On Mon, Feb 9, 2015 at 6:01 PM, Dmitry Stogov wrote:
> Usage of "return" is a good idea.
> The more heads the better result :)
>
Less additional reserved word :)
So I'll use "require" and "return" for D like RFC.
We haven't talk much about invariants. I'll write my idea.
Cur
HI Dmitry,
On Mon, Feb 9, 2015 at 7:34 PM, Yasuo Ohgaki wrote:
>
> [Without block]
> function foo() {
> require(assert-expr, 'msg');
> require(assert-expr, 'msg');
> require(assert-expr, 'msg');
> invariant(assert-expr, 'msg');
> invariant(assert-expr, 'msg');
> invariant(assert-expr
Morning Yasuo,
Can you explain what invariant is for ?
I prefer a list of contracts with a single expression, over blocks of
expressions in one contract.
An IDE can just as easy generate a block of code or set of contracts,
so it's really just a matter of how complex it makes the impl
invariant is for classes only. It should be called before and/or after each
method to check object consistency.
syntax with expressions may work if we put constraints before the function
body .
function foo($a int): int
require(expr1)
require(expr2, msg)
return(expr3)
{
}
Yasuo, I wo
Could this be described as a requirement of the class ?
class Mine
require(invariant-expr)
extends Something
implements Someface {
public function method($param) : return
require(input-expr),
return(output-expr) {
}
}
To avoid invariant keyword maybe.
Cheers
yes. this may work.
probably better to put it after extends and implements.
Dmitry.
On Mon, Feb 9, 2015 at 2:19 PM, Joe Watkins wrote:
> Could this be described as a requirement of the class ?
>
> class Mine
> require(invariant-expr)
> extends Something
> implements Someface {
>
>
Yeah, after
On Mon, Feb 9, 2015 at 11:27 AM, Dmitry Stogov wrote:
> yes. this may work.
> probably better to put it after extends and implements.
>
> Dmitry.
>
> On Mon, Feb 9, 2015 at 2:19 PM, Joe Watkins wrote:
>
>> Could this be described as a requirement of the class ?
>>
>> class Mine
Hi Dmitry,
> De : Dmitry Stogov [mailto:dmi...@zend.com]
> Envoyé : lundi 9 février 2015 12:05
> À : Joe Watkins
> Cc : Yasuo Ohgaki; Stanislav Malyshev; PHP Internals
> Objet : Re: [PHP-DEV] Design by Contract
>
> invariant is for classes only. It should be called bef
On Mon, Feb 9, 2015 at 3:57 PM, François Laupretre
wrote:
> Hi Dmitry,
>
> > De : Dmitry Stogov [mailto:dmi...@zend.com]
> > Envoyé : lundi 9 février 2015 12:05
> > À : Joe Watkins
> > Cc : Yasuo Ohgaki; Stanislav Malyshev; PHP Internals
> > Obje
Hi Dmitry and Joe,
On Mon, Feb 9, 2015 at 8:27 PM, Dmitry Stogov wrote:
> yes. this may work.
> probably better to put it after extends and implements.
>
>
> Dmitry.
>
> On Mon, Feb 9, 2015 at 2:19 PM, Joe Watkins wrote:
>
>> Could this be described as a requirement of the class ?
>>
>> class M
Hi all,
On Tue, Feb 10, 2015 at 5:19 AM, Yasuo Ohgaki wrote:
> Use of interface:
> - no additional keyword (pros)
> - requires interface for DbC, most classes does not require interface
> (cons)
> - if interface is not used, user has to repeat invariant conditions over
> and over (cons)
>
Hi all,
On Tue, Feb 10, 2015 at 5:27 AM, Yasuo Ohgaki wrote:
> On Tue, Feb 10, 2015 at 5:19 AM, Yasuo Ohgaki wrote:
>
>> Use of interface:
>> - no additional keyword (pros)
>> - requires interface for DbC, most classes does not require interface
>> (cons)
>> - if interface is not used, us
On Feb 9, 2015 11:20 PM, "Yasuo Ohgaki" wrote:
>
> Hi Dmitry and Joe,
>
> On Mon, Feb 9, 2015 at 8:27 PM, Dmitry Stogov wrote:
>>
>> yes. this may work.
>> probably better to put it after extends and implements.
>>
>>
>> Dmitry.
>>
>> On Mon, Feb 9, 2015 at 2:19 PM, Joe Watkins
wrote:
>>>
>>> Co
Morning,
A good start ... ish ...
Please steer clear of using the assert API, and in so doing avoid BC
concerns with the current assert API.
Please avoid adding a magic method and use the suggested syntax for
invariant.
class Some {
require(invariant-expr);
/* ... */
}
like that is be
Hi Dmitry,
On Tue, Feb 10, 2015 at 1:43 PM, Dmitry Stogov wrote:
> On Feb 9, 2015 11:20 PM, "Yasuo Ohgaki" wrote:
> >
> > Hi Dmitry and Joe,
> >
> > On Mon, Feb 9, 2015 at 8:27 PM, Dmitry Stogov wrote:
> >>
> >> yes. this may work.
> >> probably better to put it after extends and implements.
>
Hi Joe,
On Tue, Feb 10, 2015 at 3:16 PM, Joe Watkins wrote:
> You need to explain how invariants are going to be inherited and executed
> in detail.
>
OK. Thank you. This wouldn't change even if syntax changes.
>
> Keep statements such as
>
> > With proper use of DbC concept, it is known *pro
> Joe's idea was to use Interface for invariant condition grouping.
It wasn't, it was to use "require" at the class declaration, using it in
the class body is better still ...
Cheers
Joe
On Tue, Feb 10, 2015 at 6:27 AM, Yasuo Ohgaki wrote:
> Hi Joe,
>
> On Tue, Feb 10, 2015 at 3:16 PM, Joe Wat
Hi,
can I make some minor correction?
Thanks. Dmitry.
On Tue, Feb 10, 2015 at 9:25 AM, Yasuo Ohgaki wrote:
> Hi Dmitry,
>
> On Tue, Feb 10, 2015 at 1:43 PM, Dmitry Stogov wrote:
>
>> On Feb 9, 2015 11:20 PM, "Yasuo Ohgaki" wrote:
>> >
>> > Hi Dmitry and Joe,
>> >
>> > On Mon, Feb 9, 2015 a
1 - 100 of 214 matches
Mail list logo
