hi,
although this does not address the problem on the same level i would suggest
using a proper object layer. i posted a very short plan for one some days
ago.
attaching yet another feature to poe (session) reference handling will not
solve the problem. well it could, but developers would end up writing a lot
of cleanup code that has to be debugged and will have bugs, and that for
every application. poe reference handling certainly works and does the job,
but it is not designed to handle references with attached features: roles,
monitoring these references, ...
thus the better way is to take all information about object relations
(associations) that evolved during design and pipe them into an object
layer. this layer can do all the cleanup / monitoring stuff and it is not
hidden in several calls to different features. this way code will be much more
maintainable and easier to read, perhaps even easier to parse for doc tools
or the like.
i would suggest that we better design a proper object layer and get rid of
the problems at their roots.
this would be very good for IKC too. the more information it knows the better
can it handle all the this. e.g. if we had objects a and b, distributing them
to different kernels could be (almost) transparent. as associations between
them are not just references on both sides but real objects, these
associations can monitor calls, model roles, monitors could be attached, ...
and everything without object interaction. all that is needed is an
association declaration. method code is not affected, only constructors.
but these can be build in a way so that most of the association's properties
could be set at run oder deployment time.
please consider this approach, it would take the whole poe thing to a new
level.
torvald
