Hi Yasuo,
I just suggest you add the following notice text at the beginning of your RFC : An alternative ‘Design by Contract’ RFC exists (https://wiki.php.net/rfc/dbc). It was started by François Laupretre, is based on annotations, and proposes an alternative syntax to add contract support to PHP. The RFC is currently suspended, waiting for final decisions about scalar type hinting, and won’t be proposed for an implementation in 7.0. That’s just a suggestion. Anyway, go on with the discussion about your RFC. Don’t wait for me, as I won’t have time to propose it for 7.0. Again, if you want to be *really* fair, just insert the notice above or something similar at the top of your RFC. So people will have access to all available information before they make their decision. Thanks François De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo 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 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...@ohgaki.net On Mon, Feb 16, 2015 at 2:56 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: Hi Francois, On Mon, Feb 16, 2015 at 8:08 AM, François Laupretre <franc...@php.net> 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 is overridden, D just ignores > > contract. > > That's true for pre-conditions, but that's not the way D handles > post-conditions. > > >>> The same rule for class applies to interfaces. > >> > >> ?? I don't understand. > > > >Interface may have contracts just like class. > > OK, but when do you check interface conditions ? And how do you deal with > interface (multiple) inheritance ? Simply check all contracts on method calls. If property check (invariant) could be issue, class designer should use document for proper property management rather than contracts. Or we may drop invariant support for interface. > > >>> We cannot ignore parent class invariants. If developer violate parent > >>> property restrictions, > >>> it's violation of parent class type and this must be forbidden. It's > >>> checked by invariant contract. > >> > >> I agree. > > > > We have(had) weak type system. Choosing right type system for PHP would be > > very hard. > > I didn't intended to bring this topic... Could we introduce simple "Design > > by Contract" > > concept? Or are we going to discuss right type system for PHP? > > Sure, but are you realizing that you're discarding your own statement, not > mine ? Type safety consideration was not intended at first. So I don't have problem with disregarding type safety. We may introduce type safety/system when we have template, strict types and/or overloading, for example. > I never told about the PHP type system because I don't understand what types > have to do here. So, yes, I don't care about the PHP type system and that's > not the subject. We are discussing about PHP conditions and when they are > evaluated, that's all. > > And, sorry about that, but could you stop sending html messages ? It makes > replies much harder. It seems gmail does not have the option, but I can only remove text formatting manually. Does this mail seems OK to you? Anyway, how about not to consider type safety too much now? and concentrate to introduce simple DbC? We may have option for strict type in the future for whatever type system we introduce at that time. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
