On Friday 25 June 2004 14:30, Bill Kelly wrote:
> From: "Sean O'Dell" <sean / celsoft.com>
>
> > On Friday 25 June 2004 09:16, Bill Kelly wrote:
> > > Supposed an object's class were changed to a different class
> > > which was itself (or whose ancestor(s) were) implemented in 'C'
> > > code.  Something that expects that once it's initialized it
> > > can go ahead and rely on its class invariants pointing to real
> > > operating system file handles, window handles, etc.
> >
> > No code should "expect" data to be there that isn't.
> >
> :)
>
> No ambulator should "expect" the rug to remain steady
> under their feet when it might be pulled out from under them.

You can if it's nailed down.  You don't if it's a throw run with a rope tied 
to one end which runs out the front door and into the street.

> And yet - we live by many such expectations just to make
> it through every day life.  One such expectation, for me,
> is that when my constructor or initializer (whether it
> be C or C++ or Ruby or Java or Perl or Python or.....)
> sets up some private member variables in my object - it
> is reasonable for me to expect that they won't be tampered
> with by unexpected external tomfoolery.

This is my practice as well in Ruby.  Ruby handles such cases very well, and 
gives you good warnings when something your code needs isn't there.  It's 
very simple to handle the exceptional cases by adding some checks later on if 
you find there's a real problem.  Usually there isn't.

C is quite different, though.  You make assumptions to speed development and 
reduce code bloat, but sometimes you just can't get away with it.

	Sean O'Dell