> >In use this mechanism would look like:
> >
> >students = teacher.students.get()
> >
> >As opposed to:
> >
> >students = teacher.students
> >
>
> I had two proposals on my mind when I wrote this bit and ended up mixing them
> together. The ``Demand'' attribute is not needed if the reference is packaged
> up in a ``reference'' object that is de-referenced everytime the subobject is
> accessed. Sorry for being confusing.
>
> What I am proposing is functionally not very different from storing object IDs
> as strings, but having these references encapsulated in a special object will
> make them visible to the database engine (as well as to your python database
> layer should you later want to implement load-on-demand or some such thing).
I, too, have been thinking about this problem of demand loading. I was
calling a group of related persistent objects (e.g. tasks in a project,
entries in an email directory) a "collection". My current collections
are really just a persistent object, with a data attibute that is a list
containing the ObjIDs, and methods that support operating on a group of
objects.
This led to another concept that would be nice to add to the persistent
store -- transient objects. Scenario: you search you email directory
collection for everyone in the manager category. You get back a listing,
with several operations available. One might be email, so you choose
that, fill in Subj and Body, and it applies that to an email method for
every object in that listing. What is that listing? A transient
collection object, one that gets popped onto a queue, with a Time-To-Live.
Garbage collection removes it.
Concerning demand loading again, I was thinking of another tack: an
object registry. Under ToolTalk, you don't send methods (note: I am only
barely acquainted with TT) directly to the objects, you send them to the
ToolTalk registry. Objects register what they are interested in. That
may allow a more economical manner of loading. My Aliweb design could
have *many* objects in memory, something I'd like to avoid.
This could lead to, although I'm not sure how, an event-driven model.
Instead of stepping through a list of objects, and sending a method to
each one, just send an event to the registry. The objects should know
how to respond.
Paul Everitt V 703.785.7384 Email Paul.Everitt@cminds.com
Connecting Minds, Inc. F 703.785.7385 WWW http://www.cminds.com/