On 5/26/05, Adrian Howard <[EMAIL PROTECTED]> wrote:
> - No class invariants?
Soon!
> - You do mention that tweaking @_ in the pre/post blocks will
> affect the @_ passed to the method. You don't say that having pre/
> posts that have side effects is evil. You probably should :-)
Reflecting upon this, I'm not even sure why I'd want argument
modification as a feature. (Maybe I still had Hook::LexWrap on the
brain.) I might just take this out.
> - It's not immediately obvious to me from reading the docs that
> doing:
>
> { package SomeSubclass;
> use base 'SomeClass'; # from your example
> sub choose_word { return -1 };
> }
>
> would fail since choose_word should still be bound by the
> SomeClass precondition. I'm assuming you're doing something clever
> with INIT blocks or something so this does work.
INIT blocks? Nope, nothing clever. If you use a class' method before a
"precondition" statement, that method will simply not be bound to a
contract.
> - On "How can I type less?". I'm curious as to whether you
> considered adding an automatic $self to match the $r/@r ?
When you say "automatic," I think of source filtering. Do you simply
mean an alias for the first argument? If so, I think it's best to
leave that up to the programmer. You can always use shift.
> - I'd want a global way of switching off contracts without having
> to change the code. $ENV{ClassAgreementDisabled} = 1 or something.
Arg! This is a biggie. If used properly, you shouldn't need, let alone
*want*, to turn contracts off. Class::Agreement doesn't do any deep
cloning like Class::Contract. Class::Agreement's contracts should be
nearly as light as putting "die unless" in your methods.
I'll include that feature, but not without a big disclaimer such as the above.
> - I had to read "What do you mean, ``There's a problem with the
> heirarchy?''" three times. More paragraphs and an example for the
> slow of thinking like me please :-)
Definitely. More examples on the way.
Thanks, Adrian. This is much appreciated.
--
Ian Langworth
