Branden wrote:
> >
> > 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?
bless is the (only) way to associate a reference with a package.
Currently, if I set up a package that expects all the objects defined by it
to have some representation or another (representation R) there is nothing
stopping me from accidentally (or someone else who is being rude) blessing
some noncompliant reference into the package, resulting in the necessity
of all the consistency checking that the pre-handlers would be for (or did
I get that wrong. )
Robust object methods have to do a lot of consistency checking because there
is no guarantee that the reference labeled "duck" isn't really a chicken with
softer feathers glued to it.
What I'm arguing is that a stronger typing, that enforced a correlation between
class-label and internal-data-consistent-with-expectations, would move the
pre and post handlers from a procedural specification into a more functional
one.
We would, like in C++ or Java, define a new kind of object that embodies the
whole of what the contract is between the two components exchanging the message.
If the receiving function cannot be invoked unless it is invoked with an
argument of type ExpectedType and the only way to get an argument into that
type is to have it pass the required test, whatever that is, as defined within
the ExpectedType specification, every contract gets its own object type and
any pre or post processing becomes implied by conversion wrappers.
Am I making sense? I worry I am rushing.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"I don't care how they do it in New York"
