David L. Nicol wrote:
> We're having a blizzard in Kansas City.  After breakfasting, changing
> the litter box, and hiking to work through the snow, I am finally
> looking at Conway's RFC 271.  Guess which one of the earlier
> activites it reminds me of.
>

I'm in really doubt... Breakfasting?  ;-)



> I agree with Branden that the inheritance semantics is screwy.
> I think DesignByContract contract enforcement is best done with
> a parameter typing system of some kind (as in C++).  Proper
> objects don't get into invalid states (unless you smash them with
> hammers, of course), so with polymorphic subs, where the
> types of the arguments are part of the name of the function, and
> some restrictions on C<bless>
>
> (Did anyone RFC an extension to C<bless> that allows a type to
> define a sanity checking function?)
>
> you can't call a subroutine with an invalid argument.
>

I'm actually working on the underlying structures of Perl variables (part of
the big vtable discussion...), what is leading to underlying representation
of Perl objects. I think this could be used to allow implementation of
Design-By-Contract as an extension instead of built-in in the language, and
require the programer to explicitly specify which classes would use DBC.
It's actually a -internal thing, but I'll probably have to bring the
discussion to -language too since it's much affected by it.





>
> The C<POST> method of defining a thing that is to be done on exiting
> the current scope would make things easier rather than more complex
> in my opinion, as discusses previously.
>

In my point of view, the mechanism proposed on RFC 271 is only good for DBC,
mainly because of its inheritance semantics, so I agree with you that RFC
271 is not the best to define the thing to be done on exiting the scope.
(Please note I'm not supporting POST either, I think I'd probably go with
`continue', but I really don't want to enter that fight, I'm trying to be a
pacifist :-)



>
> If object validity checking were incorporated int C<bless> the customary
> return of an object
> [snip]
>

I don't think I quite understood you. Are you thinking `new' is the only one
that would have pre/post to validate arguments? Actually every method call
would potentially have pre/post blocks, by RFC 271. Did I get you wrong?

Hope I helped,

- Branden

Reply via email to