Re: 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 yohgaki@ohgaki.net On Mon, Feb 16, 2015 at 2:56 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > Hi Francois, > > On Mon, Feb 16, 2015 at 8:08 AM, François Laupretre <francois@php.net> > wrote: > > > > > De : yohgaki@gmail.com [mailto:yohgaki@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 > yohgaki@ohgaki.net > >