Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Re^4: Programming is combat

by TimToady (Parson)
on Jul 08, 2004 at 20:28 UTC ( #372943=note: print w/replies, xml ) Need Help??

in reply to Re^3: Programming is combat
in thread Programming is combat

DBC is integral to Perl 6. If you google for "design by contract apocalypse perl", you'll discover that it's even been mentioned in discussions here on PM.

Replies are listed 'Best First'.
Re^5: Programming is combat
by BrowserUk (Pope) on Jul 08, 2004 at 21:21 UTC

    Indeed. Sorry for having disseminated FUD. My only defense is that it had been a while since I read Apo4 and I had forgotten about PRE and POST blocks.

    One question that I couldn't answer from my (quick) reappraisal of Apo4. Is there any intent that PRE & POST blocks will be "turn-offable" (with apologies to the BG ads) via command line switch or other similar mechanism?

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    "Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon
      Certainly, that's one of the reasons we later separated them out from FIRST and LAST blocks. In any event it'd be pretty easy to redefine the grammar to make them no-ops.
Re^5: Programming is combat
by adrianh (Chancellor) on Jul 09, 2004 at 16:50 UTC
    DBC is integral to Perl 6

    Since the subject's come up ;-)

    PRE and POST will obviously handle pre-/post-conditions for methods. However - I've not spotted an easy way of expressing class invariants. Is there something that I've missed?

    Also, there do not appear be a built ins for dealing with naming conflicts as there are in languages like Eiffel. How would I rename method foo() to bar() in a sub-class and keep the pre- and post-conditions?

    Disclaimer: I've still not read A12 properly, so apologies if the answer is in there and I missed it when I skimmed it :-)

      It should be possible to do class invariants one way or another. Perhaps we could just say that any PRE and POST properties on the class itself automagically get attached to any methods defined in the class.

      As for naming conflicts, A12 does talk about that some in the context of Roles, but similar reasoning applies to inherited methods. In general, renaming violates Liskov substitutability, so we discourage (but do not prevent) that approach in favor of distinguishing via multiple dispatch where possible, and use of a switch method where not. But in cases where renaming is used, it'll be important to make sure the correct PRE and POST are called at each level. If renaming is done simply by a wrapper method in the derived class, this will happen automatically, I suspect.

      Nonetheless, if you're changing the contract of a class, you probably ought to consider delegation instead of inheritance. And the delegation mechanism certainly has plenty of hooks for renaming.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://372943]
[marto]: good morning all
[Corion]: Hi marto!

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (8)
As of 2017-08-21 09:13 GMT
Find Nodes?
    Voting Booth?
    Who is your favorite scientist and why?

    Results (319 votes). Check out past polls.