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/
