Container Objects Enforcing Contents

[Gustavo Cordova]

>
> On 13-Feb-2002 jim kraai wrote:
> > Greetings,
> > 
> > I'm looking for suggestions on making container objects which must,
> > may, or must not allow particular kinds of container objects to be
> > added.
> > 
> > Any suggestions on a general approach for this?
> 
> Let's see .......
> 
> a constraints approach:
> 
> [ ... snip ... ]
> 
> You could also try to enforce types by ensuring the type of 
> item matches types
> you know about.  This often leads to a maintenance nightmare though.
> 

I agree, and also I add that you'd be cutting off lots of flexibility
given by Python's OO capabilities.

Let's say that, for a Select() object, you want in it's constructor's
argument, a list of options. The options must be 2-tuples with
it's value and text. That sounds nice and fine, so you validate
that the constructor's argument must be a list, and each element
a 2-tuple.

BUT... what if I want to initialize the select from a database,
so I create an object that behaves "kinda" like a list, returning
as each element a recordset with two elements, containing the
value and text. Why? Because I want to select an ... apartment,
where allocations change daily, so I want to make this as
dynamic as possible:

	class KindaArrayFromDB:
	  def __init__(self, queryString):
	    dbc = GetConnectionFromSomewhere()
	    self.query = dbc.query(queryString)
	    # Everything's nice and dandy.

	  # I'm such a smartypants, I'll redefine __getitem__
	  def __getitem__(self, key):
	    # I'll just return the next recordset and ignore the key.
	    row = self.query.NextRecord()
	    if row is None:
		raise IndexError("Nay! I say: Nay!")
	    return (row["id"], row["descr"])

	  # Just so they say I play by the roolz.
	  def __del__(self):
	    self.query.close()

So here we have our kinda-array. Once the query's initialized,
you can comfortably do a

	for t in KindaArrayFromDB("SELECT ..."):
	  do_something_with_the_results(t)

Kinda neat. But if you're checking your arguments for
compliance with a certain type, your tying it to your
way of thinking how to program, and limiting it's
usefulness.

So... Let's act like adults, shall we?

I believe that programming is an INTENTIONAL process,
where, one does things intentionally. Since you're goint
to thoroughly document your code, anybody who wishes to
use it can read the documents and know how it works and
--more importantly-- how it DOESN'T work.

So, if someone want's to make his programs crash hideously
by using your routines in an incorrect manner, by all means,
let them.

But, if someone want's to be a smartypants and use your
code in creative ways you'd never thought of, don't tie
up your code so that it becomes inflexible.

That one of the things which makes python so fun and so
beatiful, it's practically limitless.

Have a nice evening!!!
-- 
Gustavo Córdova Avila
*  gcordova at sismex.com <mailto:gcordova at sismex.com> 
* 8351-3861 | 8351-3862