Garrett Goebel writes: : ------_=_NextPart_001_01C1A506.D9BE78D0 : Content-Type: text/plain; : charset="iso-8859-1" : : From: Larry Wall [mailto:[EMAIL PROTECTED]] : > : > Garrett Goebel writes: : > : And this is just looking at it in the simple case. When : > : multiple-dispatch comes into the picture, then we'll : > : have different invokations of the same method being : > : dispatched to different implementations depending on : > : the parameter list. I wonder how PRE/POST will work : > : once that can of worms has been opened? : > : > I strongly suspect that DbC and multimethods are, at best, orthogonal. : > My gut level feeling is that multimethod calls look like ordinary : > subroutine calls, and the "method" eventually selected evaluates only : > its own PRE/POST conditions, which could perhaps explicitly : > delegate to other PRE/POST conditions. If you want more than that, : > you'll have to give me a PhD. :-) : : I thought I had ;) : : That is after all, one of the reasons why I'm a continuing contributor to : the Damian Conway fund.
And that is very much appreciated by all of us! : Would it be as easy as allowing "global" PRE/POST condition blocks to be : associated with an abstract method, and having a derived multimethod's : implementation inherit the PRE/POST conditions from those inherited : implementations which match the same parameter list? Er... for some : definition of match. That's a gross oversimplification isn't it? Every statement about DbC is oversimplified. Every statement about multimethods is oversimplified. Every statement about both is doubly oversimplified. Whether that's gross is simply a matter of taste. Larry
