I wholeheartedly support the approach BJ is advocating.
The notion that methods (functions) and variables (tables)
can be defined together is a very useful OO approach.
I too find it difficult to recall which functions "belong"
to which tables. Of course, some of my functions are very
generic and wouldn't appropriately "belong" to any one table,
but many are meant solely to operate on data in one type of
object (table).
I've taken to using schemas to collect together functions and tables
that "belong" together. This requires the use of the schema name,
as you say BJ,
> ... so I'm not passionately attached to the idea of being able to call
> the method without prefixing the table name.
In my approach, the schema name becomes the object name and the
functions "belong" to the schema. Most OO approaches only allow one
definition of variables (tables), and I can easily allow each schema
to have only one table. But I can also use multiple tables.
The extra tables can be instances, much like BJ's use of rows as
instances. Using separate tables allows me to have groups of
instances that are grouped together for some reason. I can also
have tables that are sub-classes of the original table.
TJ
http://www.gnova.com/