[development] object.module (was nodify.module idea: 'everything is a node')

[Peter Wolanin]

A quick summary of my thoughts on this;

I disagree with some of the recent posts that seem to suggest putting
all dupal "'objects" into one table.  This has the same drawbacks as
making everything a node.

I'd much rather see an effort to build a single consistent API for all
core and contrib-defined objects. Each of these object types would
still have their own primary table (and possibly a revisions table).

For example, rather than doing node_load(), user_load(), comment_load,
etc, I'd like to be able to do:

$node = drupal_load('node', $node_id);
$user = drupal_load('user', $user_id)
...

Assume $class = 'node', then when loading a node drupal_load() would
call something like:

$object = db_fetch_object(db_query("SELECT * FROM {%s} WHERE %s_id =
%d", $class, $class, $id"));
$extra = module_invoke_all($class .'_load', $object);

The node module would declare a function (e.g. node_class_define())
that would return a list of all the fields in the node table for
saving/inserting.   Modules could optionally also define type object
for their objects (i.e. node_type objects).

This would mean any contrib module could define this one function and
install the table and automatically get all the load, save, hook, etc.
code for free.

Menu module could even automatically define a standard set of
non-cached paths and tabs like

$class/$id/edit
$class/$id/view
$class/$id/revisions

for each module that defines a drupal object, making the devel's life
even easier.

Anyhow, obviously the devil's in the details, but this sort of unified
API seems much more valuable to me rather than tying to deny the
uniqueness of each type of data by throwing them all in one enormous
object table.  This would seem also to move towards getting more of
the advantages of OO programming, without getting hung up on the
different support for objects in different PHP versions.

-Peter