Hi Dmitry,
On Wed, Mar 4, 2015 at 5:35 PM, Dmitry Stogov wrote:
> assert() is not for DbC. It''s useful by it's own. However, new zero-cost
> assert() implementation should be reused for true DbC.
I fully agree.
I cannot wait to have it.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Tue, Mar 3, 2015 at 10:04 PM, Yasuo Ohgaki wrote:
> Hi Dmitry,
>
> On Mon, Mar 2, 2015 at 4:20 PM, Dmitry Stogov wrote:
>
>> It may be to late for 7.0.
>>
>
> I feel the same way. It may be better to try add it with 7.x.
>
>
>> Also Alexander liked to to add another proposal, but I saw only
>
Hi Dmitry,
On Mon, Mar 2, 2015 at 4:20 PM, Dmitry Stogov wrote:
> It may be to late for 7.0.
>
I feel the same way. It may be better to try add it with 7.x.
> Also Alexander liked to to add another proposal, but I saw only
> pre-required one(s)
> Anyway, it's not a big problem to vote now.
>
Hi Yasuo,
It may be to late for 7.0.
Also Alexander liked to to add another proposal, but I saw only
pre-required one(s)
Anyway, it's not a big problem to vote now.
I may take care about implementation for https://wiki.php.net/rfc/dbc2 (but
only if it wins).
Thanks. Dmitry.
On Sun, Mar 1, 2015 a
Hi all,
I made vote only RFC and started discussion for voting
https://wiki.php.net/rfc/introduce_design_by_contract
Please feel free to correct/improve it.
I added note to our RFCs
https://wiki.php.net/rfc/dbc
---
This RFC is part of “Design by Contract Introduction” RFC
https://wiki.php.net/r
Ohgaki
Envoyé : mercredi 25 février 2015 22:32
À : francois
Cc : Dmitry Stogov; Joe Watkins; Stanislav Malyshev; PHP Internals
Objet : Re: [PHP-DEV] Design by Contract
Hi all,
I would like to start [DISCUSSION] for this RFC.
RFC may needs update, but these changes can be done during the
Hi all,
I would like to start [DISCUSSION] for this RFC.
RFC may needs update, but these changes can be done during the discussion
also.
Any comments for staring discussion?
P.S. I'll prepare simple "Vote Only" RFC for 2 RFCs. Please feel free to
change/improve it.
--
Yasuo Ohgaki
yohg...@ohga
Hi Francois,
On Mon, Feb 16, 2015 at 8:08 AM, François Laupretre
wrote:
>
> > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
Ohgaki
> >
> > D resolves that if parameter is contract or not at compile time and
checks it if method
> > is overriding parent's method. If method i
> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
>
> D resolves that if parameter is contract or not at compile time and checks it
> if method
> is overriding parent's method. If method is overridden, D just ignores
> contract.
That's true for pre-conditions, but th
Hi Francois,
On Mon, Feb 16, 2015 at 1:08 AM, François Laupretre
wrote:
>
> > Now I understand what you are discussing. Since we may have stricter
> > typing, we probably better
> > to consider type safety theory even if PHP is weakly typed.
>
> I am not sure it was about types, it was about cond
> - Consider introduction of static require() as class invariant for static
> methods
>
invariant contacts are executed in object methods. I meant adding "static
invariant" to be executed on static methods.
but I think we don't need them at this point.
>
> I probably don't understand the idea c
Hi Yasuo,
>
> Now I understand what you are discussing. Since we may have stricter
> typing, we probably better
> to consider type safety theory even if PHP is weakly typed.
I am not sure it was about types, it was about conditions...
> Pre/Postconditions should be checked only when parent metho
Hi François
> -Ursprüngliche Nachricht-
> Von: François Laupretre [mailto:franc...@php.net]
> Gesendet: Sonntag, 15. Februar 2015 11:43
> An: 'Robert Stoll'; 'Yasuo Ohgaki'
> Cc: 'Dmitry Stogov'; 'Joe Watkins'; 'Stanislav M
> De : Robert Stoll [mailto:p...@tutteli.ch]
>
> The theory is actually quite simple. Roughly it says that if you use a type
> hint
> of a certain class then you can rely on all pre/post-conditions of this class
> even if a sub-class is passed. Hence the sub-class cannot have more restrict
> condi
On Sun, Feb 15, 2015 at 8:17 AM, Yasuo Ohgaki wrote:
> I wrote simple D program "sample.d" to play with. Install D, then
>
> dmd sample.d && ./sample
>
> sample.d
> import std.stdio;
>
> class A {
> int x = 1;
> int y = 2;
>
> public:
> void set (int x, int y)
> in {
> assert(x > 0);
> a
Hi all,
On Sun, Feb 15, 2015 at 8:25 AM, Yasuo Ohgaki wrote:
> Both D and Eiffel has way to get around it.
> As I mentioned in previous mails, PHP may be get around with it by default
> because it's the nature of PHP. PHP may be extended to follow type theory
> in the future when strict_types is
Hi Robert,
On Sun, Feb 15, 2015 at 8:14 AM, Robert Stoll wrote:
> I think you misunderstood me, I did not have any questions, I merely
> wanted to explain to François what LSP means, but thanks anyway :)
I understood. You are correct.
Both D and Eiffel has way to get around it.
As I mentioned
Hi all,
On Sun, Feb 15, 2015 at 7:53 AM, Yasuo Ohgaki wrote:
> On Sat, Feb 14, 2015 at 8:06 PM, Robert Stoll wrote:
>
>> The theory is actually quite simple. Roughly it says that if you use a
>> type hint of a certain class then you can rely on all pre/post-conditions
>> of this class even if a
Hi Yasuo
> -Ursprüngliche Nachricht-
> Von: yohg...@gmail.com [mailto:yohg...@gmail.com] Im Auftrag von Yasuo Ohgaki
> Gesendet: Samstag, 14. Februar 2015 23:54
> An: Robert Stoll
> Cc: francois; Dmitry Stogov; Joe Watkins; Stanislav Malyshev; PHP Internals
> Betreff: Re
Hi Robert,
D and PHP differs a lot with respect to types. D is very strongly typed
while PHP is very weakly typed.
Therefore, we need a little different approach.
On Sat, Feb 14, 2015 at 8:06 PM, Robert Stoll wrote:
> The theory is actually quite simple. Roughly it says that if you use a
> type
All: I'll be continuing work on the RFC tomorrow, it is still in draft.
Yasuo: I'll read through your notes tomorrow, thanks for detailed input.
Cheers
Joe
On Sat, Feb 14, 2015 at 9:17 AM, Yasuo Ohgaki wrote:
> Hi Francois,
>
> Now I understand what you are discussing. Since we may have strict
> -Ursprüngliche Nachricht-
> Von: François Laupretre [mailto:franc...@php.net]
> Gesendet: Samstag, 14. Februar 2015 07:17
> An: 'Yasuo Ohgaki'
> Cc: 'Dmitry Stogov'; 'Joe Watkins'; 'Stanislav Malyshev'; 'PHP Internals
Hi Francois,
Now I understand what you are discussing. Since we may have stricter
typing, we probably better
to consider type safety theory even if PHP is weakly typed.
What I'm going to write is not type theory, though.
On Sat, Feb 14, 2015 at 3:16 PM, François Laupretre
wrote:
>
> The theory
t : Re: [PHP-DEV] Design by Contract
Hi Francois,
On Sat, Feb 14, 2015 at 12:53 PM, Yasuo Ohgaki wrote:
On Sat, Feb 14, 2015 at 12:03 PM, François Laupretre wrote:
> For method calls, overridden method should not evaluate parents contract on
> entry.
> It should be evaluated whe
> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
>
>Open discussion is needed, of course.
>What I meant is discussion for writing up draft RFC is close to finish.
That's fine.
> > For method calls, overridden method should not evaluate parents contract on
> > entry.
>De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
>
>Did you mean "Least Concern Principle" here?
No : http://en.wikipedia.org/wiki/Liskov_substitution_principle.
IMO, it is just a sort of best practice but OO people love it.
François
--
PHP Internals - PHP Runtime
Hi Francois,
On Sat, Feb 14, 2015 at 12:53 PM, Yasuo Ohgaki wrote:
> On Sat, Feb 14, 2015 at 12:03 PM, François Laupretre
> wrote:
>
>> > For method calls, overridden method should not evaluate parents
>> contract on entry.
>> > It should be evaluated when parent method is called.
>>
>> I alrea
Hi Francois,
On Sat, Feb 14, 2015 at 12:03 PM, François Laupretre
wrote:
> > For method calls, overridden method should not evaluate parents contract
> on entry.
> > It should be evaluated when parent method is called.
>
> I already told you : the logic you are using for pre-conditions is NOT
>
Hi all,
On Sat, Feb 14, 2015 at 12:03 PM, François Laupretre
wrote:
>
> > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
Ohgaki
> >
> > We have discussed most of issues for https://wiki.php.net/rfc/dbc2
>
> I am not sure anyone except hardly 5 people has the impression that
Hi Yasuo,
> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
>
> We have discussed most of issues for https://wiki.php.net/rfc/dbc2
I am not sure anyone except hardly 5 people has the impression that the subject
was discussed, as the RFCs were not even officially anno
On Sat, Feb 14, 2015 at 8:19 AM, Yasuo Ohgaki wrote:
> myMethod() {
> require(MyMethod());
> }
>
My hand is not used to new syntax yet. This should be.
myMethod()
require(myMethid())
{
/* */
}
==
Native DbC support syntax:
class Child {
require($this->age <
Hi all,
We have discussed most of issues for https://wiki.php.net/rfc/dbc2
==Missing parts of the RFC for me==
- Advantage over annotation:
Written as code, executed as code. ("Written as document, available
as document" would be
annotation advantage)
- Advantage over assert() onl
Hi,
On Wed, Feb 11, 2015 at 10:05 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > That one actually looks better to me, but: I'm not sure how
> annotation
> > syntax is supposed to support expressions or closures,
> >
> >
> > keep AST.
>
> So we'd have a zval type that is the raw AST? Would it
Hi!
> That one actually looks better to me, but: I'm not sure how annotation
> syntax is supposed to support expressions or closures,
>
>
> keep AST.
So we'd have a zval type that is the raw AST? Would it also be available
to user functions or internal functions/classes? It's an intrigu
On 11/02/15 14:14, François Laupretre wrote:
>> All of the current demands ... and I think they are demands! ... stamp
>> > on past history and load even more work on everybody to have to support
>> > all these new features. Even if dbc is wrapped in comment blocks to hide
>> > it it's potential pr
Hi Lester,
> All of the current demands ... and I think they are demands! ... stamp
> on past history and load even more work on everybody to have to support
> all these new features. Even if dbc is wrapped in comment blocks to hide
> it it's potential presence in third party parts of a project me
> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
> Ohgaki
>
> Both D and Eiffel evaluates all contracts defined in parents/interfaces.
That's not what I understand about pre-condition inheritance in D (check
http://ddili.org/ders/d.en/invariant.html#ix_invariant.contract%20
> De : Dmitry Stogov [mailto:dmi...@zend.com]
>
> I think we should just repeat the related D semantic.
> It must be defined in contracts inheritance rules.
>
> What if we have contracts for prototype method in parent class and
> interface?
> Should we still validate contracts of parent and inter
2015-02-11 13:25 GMT+02:00 Dmitry Stogov :
>
> yes. some special attributes. requires/ensures/invariant
>
>
>> Oh, and <<>> syntax is *ugly* ;)
>>
>
> It's from HHVM. I don't like it as well, please, propose the better one.
>
I like syntax, like a switch:
function add(int $a, int $b) : int
ca
On Wed, Feb 11, 2015 at 10:58 AM, Stanislav Malyshev
wrote:
> Hi!
>
> > 1) contracts in doc-commetns https://wiki.php.net/rfc/dbc
> >
> > /**
> > * @requires ($a >= 0)
> > */
> > function foo($a) {
> > }
>
> We've spent several years rejecting annotations because no information
> can be in comm
On 11/02/15 07:58, Stanislav Malyshev wrote:
> We've spent several years rejecting annotations because no information
> can be in comments, not even a little bit, not even a tiny.
I find that a strange comment, since I've been using annotation in PHP
from day one. The phpdoc material helped me get
"Stanislav Malyshev" wrote in message news:54dafd32.3000...@gmail.com...
Hi!
Please steer clear of using the assert API, and in so doing avoid BC
concerns with the current assert API.
The operator can be called something other than "assert", I'm sure the
thesaurus has a lot of possibilities
> http://dlang.org/deprecate.html#invariant as an alias for immutable
It's not an alias, the most recent compiler emits an error if you try to
use invariant contracts, and immutable isn't a kind of contract.
immutable is a property modifier:
immutable: http://dpaste.dzfl.pl/7e724b599640
invarian
Hi Joe,
On Wed, Feb 11, 2015 at 5:12 PM, Joe Watkins wrote:
> > Just a thought - what about something like __pre/__post? We own __*, so
> no BC problems.
>
> I'm not married to the words being used, at all.
>
> I think this is a good idea, we would need __pre, __post , and
> __invariant, or some
Hi Joe,
On Wed, Feb 11, 2015 at 5:02 PM, Yasuo Ohgaki wrote:
> On Wed, Feb 11, 2015 at 4:54 PM, Joe Watkins
> wrote:
>
>> So it turns out that invariant is already deprecated in D, they have
>> dropped it in favour of immutable properties.
>>
>> I guess I'll have to install an old version, or t
> OTOH, don't our new parsing improvements allow us to handle syntax like
this without introducing a keyword that would be forbidden as
class/function name
Not that I am aware of, the AST stuff didn't touch the parser like that, it
has the same limitations it had before AFAIK.
Cheers
Joe
On Wed,
> Just a thought - what about something like __pre/__post? We own __*, so
no BC problems.
I'm not married to the words being used, at all.
I think this is a good idea, we would need __pre, __post , and __invariant,
or some combination of three.
Any objection to using __ prefixed names, and any o
Hi!
>> function foo($a)
>> require($a >= 0)
>> {
>> }
>
> This is a step better but still we have the similar issues with
> readability, to which reuse of 'require' is added.
Just a thought - what about something like __pre/__post? We own __*, so
no BC problems.
OTOH, don't our new parsing i
Hi Joe,
On Wed, Feb 11, 2015 at 4:54 PM, Joe Watkins wrote:
> So it turns out that invariant is already deprecated in D, they have
> dropped it in favour of immutable properties.
>
> I guess I'll have to install an old version, or try to extract everything
> we need from their obviously outdated
Hi!
> 1) contracts in doc-commetns https://wiki.php.net/rfc/dbc
>
> /**
> * @requires ($a >= 0)
> */
> function foo($a) {
> }
We've spent several years rejecting annotations because no information
can be in comments, not even a little bit, not even a tiny. Now we'd
have full-blown running code
So it turns out that invariant is already deprecated in D, they have
dropped it in favour of immutable properties.
I guess I'll have to install an old version, or try to extract everything
we need from their obviously outdated documentation ...
Grrr ...
Cheers
Joe
On Wed, Feb 11, 2015 at 7:50 A
Hi Dmitry,
On Wed, Feb 11, 2015 at 4:26 PM, Dmitry Stogov wrote:
> I think we should just repeat the related D semantic.
> It must be defined in contracts inheritance rules.
>
> What if we have contracts for prototype method in parent class and
> interface?
> Should we still validate contracts o
> I think we should just repeat the related D semantic.
I'm not sure it all fits, some decisions were likely taken because of D's
object model.
I'm going to continue research today and will be updating the RFC, I'll aim
for as close to D as possible then.
Cheers
Joe
On Wed, Feb 11, 2015 at 7:26
So, I think we have to support them as well.
On Wed, Feb 11, 2015 at 10:12 AM, Yasuo Ohgaki wrote:
> Hi Dmitry and Joe,
>
> On Wed, Feb 11, 2015 at 4:02 PM, Dmitry Stogov wrote:
>
>> I think we can't support contracts on interfaces and abstract methods.
>> How D works?
>
>
> D supports contract
it's possible to achieve the same validation just with assert() spread over
the code.
It's nothing wrong with this, but this is not DbC.
The question, if we need DbC at all, is still open.
Thanks. Dmitry.
On Wed, Feb 11, 2015 at 10:05 AM, Stanislav Malyshev
wrote:
> Hi!
>
> > Hello, internals!
I think we should just repeat the related D semantic.
It must be defined in contracts inheritance rules.
What if we have contracts for prototype method in parent class and
interface?
Should we still validate contracts of parent and interface if we add our
owns?
etc.
Thanks. Dmitry.
On Wed, Feb 1
Hi Stas,
I agree, it may look weird at first, but if you familiar with concept it
looks more or less natural. It's implemented in D, Effiel, it was a
proposal for Java, etc
Anyway, we will have at least 3 competing proposals.
1) contracts in doc-commetns https://wiki.php.net/rfc/dbc
/**
* @req
> If there is no technical difficulties, I would like to have it.
Okay then, I'll rethink ...
Cheers
Joe
On Wed, Feb 11, 2015 at 7:12 AM, Yasuo Ohgaki wrote:
> Hi Dmitry and Joe,
>
> On Wed, Feb 11, 2015 at 4:02 PM, Dmitry Stogov wrote:
>
>> I think we can't support contracts on interfaces an
> I still don't see what's wrong with just putting the code
at the beginning of the function and whenever you want to check it
That makes inheritance of contracts awkward/impossible/impractical:
class Some {
public function method() {
assertOrWhatever($expr);
}
}
class Other exte
Hi Dmitry and Joe,
On Wed, Feb 11, 2015 at 4:02 PM, Dmitry Stogov wrote:
> I think we can't support contracts on interfaces and abstract methods.
> How D works?
D supports contract in structure and interface. Structure is more like
classes in D, though.
interface I
{
int foo(int i)
in
> I think reusing syntax for existing operator in completely unrelated
context is a big mistake.
I keep hearing that, I agree, but adding keywords presents it's own
problems.
The keywords can always be changed, maybe they can be a voting option even.
Cheers
Joe
On Wed, Feb 11, 2015 at 6:56 AM,
D has them:
http://dlang.org/interface.html#interface-contracts
Maybe we could allow pre/post contracts but invariants don't make sense on
interfaces.
The question is, do we want to make them always available when possible, or
do we want to make them available where it seems most useful and or l
Got it, but currently we don't declare internal classes/interfaces in PHP.
We do it with internal C API, of course we may extend it to support
contracts, but it looks too complex for C.
It's easier to make all necessary validation directly in C code.
I don't think we should propose something relate
Hi!
> Hello, internals!
>
> DbC is good thing, but the way you want to do this via language changes is
> really awful. Why do you want to add more custom features into the
Agreed here. I still don't see what's wrong with just putting the code
at the beginning of the function and whenever you wan
I think we can't support contracts on interfaces and abstract methods.
How D works?
Thanks. Dmitry.
On Wed, Feb 11, 2015 at 1:56 AM, Yasuo Ohgaki wrote:
> Hi Dmitry and Joe,
>
> On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki wrote:
>
>> On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov wrote:
>>
> I didn't get what do you mean by " internal module"
He means extension, builtin classes/functions.
Cheers
Joe
On Wed, Feb 11, 2015 at 7:00 AM, Dmitry Stogov wrote:
> I didn't get what do you mean by " internal module"
>
> Thanks. Dmitry.
>
> On Wed, Feb 11, 2015 at 12:29 AM, Yasuo Ohgaki wr
I didn't get what do you mean by " internal module"
Thanks. Dmitry.
On Wed, Feb 11, 2015 at 12:29 AM, Yasuo Ohgaki wrote:
> Hi Dmitry and Joe,
>
> On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov wrote:
>
>> You are welcome to edit https://wiki.php.net/rfc/dbc2
>> It looks like we have similar v
Hi!
> Please steer clear of using the assert API, and in so doing avoid BC
> concerns with the current assert API.
The operator can be called something other than "assert", I'm sure the
thesaurus has a lot of possibilities.
> Please avoid adding a magic method and use the suggested syntax for
>
> We have related issue like how internal module incorporate with DbC.
However
these could be future issues.
I think this should be an additional RFC, so we'll put this under future
issues I think.
> A little more clarification, following interface definition is allowed
or not?
Currently, we're
Hi Dmitry and Joe,
On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki wrote:
> On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov wrote:
>
>> You are welcome to edit https://wiki.php.net/rfc/dbc2
>> It looks like we have similar views, so just make it better in a way you
>> think.
>>
>
> Looks good to m
Hi Dmitry and Joe,
On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki wrote:
> On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov wrote:
>
>> You are welcome to edit https://wiki.php.net/rfc/dbc2
>> It looks like we have similar views, so just make it better in a way you
>> think.
>>
>
> Looks good to m
Hi Dmitry and Joe,
On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki wrote:
> On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov wrote:
>
>> You are welcome to edit https://wiki.php.net/rfc/dbc2
>> It looks like we have similar views, so just make it better in a way you
>> think.
>>
>
> Looks good to m
Hi Dmitry and Joe,
On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov wrote:
> You are welcome to edit https://wiki.php.net/rfc/dbc2
> It looks like we have similar views, so just make it better in a way you
> think.
>
Looks good to me. It's much better than original. Thank you folks.
We have relat
Hi Yasuo,
Le Tue, 10 Feb 2015 07:25:00 +0100, Yasuo Ohgaki a
écrit:
Updated wiki page.
https://wiki.php.net/rfc/dbc2
While I agree this RFC is going in the right direction, I don't like the
use of "require" and "return".
They are already used for something completely different, I think
Hi Alexander,
> De : Alexander Lisachenko [mailto:lisachenko...@gmail.com]
>
> This is built on top of reflection+annotation+parser extension.
> Why not to implement this for PHP? From my point of view, this is just an
> additional feature, that can be used by limited number of developers.
I lik
2015-02-10 15:35 GMT+03:00 Pavel Kouřil :
> Hello,
>
> maybe you could try to consult your ideas with Ivan Enderlin. He
> mentioned in previous emails (for instance
> http://news.php.net/php.internals/82245) that he would prefer some
> AOP/hook-based approach to DbC as well, so it may be compatibl
On Tue, Feb 10, 2015 at 1:30 PM, Alexander Lisachenko
wrote:
> 2015-02-10 15:20 GMT+03:00 Dmitry Stogov :
>
>> I thought about this way, and you are welcome to start composing another
>> RFC. it makes sense and has its advantages.
>> Unfortunately, it relays on many unavailable features that has t
2015-02-10 15:20 GMT+03:00 Dmitry Stogov :
> I thought about this way, and you are welcome to start composing another
> RFC. it makes sense and has its advantages.
> Unfortunately, it relays on many unavailable features that has to be
> designed as well (annotations, AST manipulation, opcode manip
Hi Alexander,
On Tue, Feb 10, 2015 at 2:44 PM, Alexander Lisachenko <
lisachenko...@gmail.com> wrote:
> Hello, internals!
>
> DbC is good thing, but the way you want to do this via language changes is
> really awful. Why do you want to add more custom features into the
> language, instead of prov
2015-02-10 15:10 GMT+03:00 Alexander Lisachenko :
> I would like to see a language with good extension API. For now, it's
> almost impossible to extend a parser, even from extension level (however,
> PHP7 will have a hook for that, thanks God).
To understand how it can be implemented, just read
2015-02-10 14:56 GMT+03:00 Patrick Schaaf :
> Ahem. Any open ended API-for-frameworks will A) force me to pick a
> framework and bend to the way it wants these things to look, and B) result
> in fragmentation and incompatibilities for any two pieces of code/library
> developed with different such
Am 10.02.2015 12:45 schrieb "Alexander Lisachenko" :
>
> DbC is good thing, but the way you want to do this via language changes is
> really awful. Why do you want to add more custom features into the
> language, instead of providing an API to extend it in a more natural way
by
> framework develope
Hi Joe,
You are welcome to edit https://wiki.php.net/rfc/dbc2
It looks like we have similar views, so just make it better in a way you
think.
Thanks. Dmitry.
On Tue, Feb 10, 2015 at 11:49 AM, Joe Watkins wrote:
> I'm happy to clean up the RFC after Dmitry's changes are merged.
>
> Happy to aut
Hello, internals!
DbC is good thing, but the way you want to do this via language changes is
really awful. Why do you want to add more custom features into the
language, instead of providing an API to extend it in a more natural way by
framework developers?
Many existing implementation of DbC is
Hi Joe,
On Tue, Feb 10, 2015 at 4:40 PM, Joe Watkins wrote:
> It doesn't seem to make sense to do that, a derived class should be able
> to define additional contracts, but not change the contracts of it's parent.
I forgot that invariants in D and Eiffel implicitly inherits parent's
invariants
On 09/02/15 23:47, Yasuo Ohgaki wrote:
> The RFC draft is ready.
> https://wiki.php.net/rfc/dbc2
> These contracts are evaluated development time only. Therefore, there is no
> performance penalty with DbC.
Sorry but that makes no sense to me at all. If this is something only to
use with an IDE
> may be something similar to Smaltalk block syntax: return(,
[, ])
That's a good approximation of perfect, I think ... looks okay to me.
Cheers
Joe
On Tue, Feb 10, 2015 at 10:21 AM, Dmitry Stogov wrote:
> D uses block syntax:
>
> ensure(ret) {
> }
>
> In this case, passing 'ret' as a 'parame
D uses block syntax:
ensure(ret) {
}
In this case, passing 'ret' as a 'parameter' looks more or less natural.
In our case, two sets of brackets looks weird.
Predefined variable or constant looks better.
A agree, __RETURN__ is longer than $ret, but it also won't conflict with
other variables.
I d
-
> > Von: Dmitry Stogov [mailto:dmi...@zend.com]
> > Gesendet: Dienstag, 10. Februar 2015 08:06
> > An: Joe Watkins
> > Cc: Yasuo Ohgaki; PHP Internals; Stanislav Malyshev
> > Betreff: Re: [PHP-DEV] Design by Contract
> >
> > good point, but I think we c
The solution D uses is allowing the programmer to declare the name of the
return value like, we could do something like:
public function method()
return ($result) ($result <= 10 && $result >= 0) {
return 5;
}
If you didn't need the result, were working with a scope variable, or maybe
even
7;$this->a >
100');
Cheers,
Robert
> -Ursprüngliche Nachricht-
> Von: Dmitry Stogov [mailto:dmi...@zend.com]
> Gesendet: Dienstag, 10. Februar 2015 08:06
> An: Joe Watkins
> Cc: Yasuo Ohgaki; PHP Internals; Stanislav Malyshev
> Betreff: Re: [PHP-DEV] Design by C
I think __RETURN__ is better than $ret.
Dmitry.
On Tue, Feb 10, 2015 at 12:43 PM, Patrick Schaaf wrote:
> Am 10.02.2015 09:29 schrieb "Dmitry Stogov" :
> >
> > I cnahged $> into $ret, because $> just won't work. Some better solution
> is welcome.
>
> Also think $> would be awful. Don't like $re
Am 10.02.2015 09:29 schrieb "Dmitry Stogov" :
>
> I cnahged $> into $ret, because $> just won't work. Some better solution
is welcome.
Also think $> would be awful. Don't like $ret either. What about a magic
constant __RETURN__ or __RESULT__? This would stand out very well when
glancing at the exp
I'm happy to clean up the RFC after Dmitry's changes are merged.
Happy to author some of the content if Yasuo is busy or wants help ?
Cheers
Joe
On Tue, Feb 10, 2015 at 8:29 AM, Dmitry Stogov wrote:
> A bit updated version of RFC is attached.
> As I removed more than added, I decided not to pu
completely agree. contracts must be permanent.
Thanks. Dmitry.
On Tue, Feb 10, 2015 at 10:40 AM, Joe Watkins wrote:
> Example code never works, I can just say that's a bad abstraction,
> vertebrate and invertebrate are distinct and abstraction should reflect
> that.
>
> Why should we provide a
Am 10.02.2015 08:25 schrieb "Yasuo Ohgaki" :
>
>> 5) and a bit off-topic, it would be useful to be able to declare (sic)
whole methods to be nonproduction only: Methods that will only be used in
pre/post/invariant condition expresions (or error formatters a la my point
4)
>
> Do you mean enable DbC
Example code never works, I can just say that's a bad abstraction,
vertebrate and invertebrate are distinct and abstraction should reflect
that.
Why should we provide a way to change contracts is the question ?
It doesn't seem to make sense to do that, a derived class should be able to
define add
Hi Joe,
On Tue, Feb 10, 2015 at 4:31 PM, Joe Watkins wrote:
> Actually I'm not sure it's at all sane to try to override contracts, I'd
> actually avoid that completely, so no need to name contracts and no need
> for magic __invariant.
For example,
class Animal {
protected $legs;
require
Am 10.02.2015 08:08 schrieb "Yasuo Ohgaki" :
>
> One reason I would like to use __invariant() is to allow overriding
parents.
> I think we should have way for it, but I don't have good idea now.
> I'm still thinking.
Hmm, Idea... Imagine the require keyword, in the context of classes, as an
altern
Actually I'm not sure it's at all sane to try to override contracts, I'd
actually avoid that completely, so no need to name contracts and no need
for magic __invariant.
Cheers
Joe
On Tue, Feb 10, 2015 at 7:26 AM, Yasuo Ohgaki wrote:
> Hi Dmitry,
>
> On Tue, Feb 10, 2015 at 4:21 PM, Dmitry Stogo
1 - 100 of 214 matches
Mail list logo
