01-06-22 02.35, skrev [EMAIL PROTECTED] p�
[EMAIL PROTECTED] f�ljande:
> 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
>
I don't see how this is relevant.
A) I agree we need some kind of object layer, I think Rocco should tread
this path ahead of us
B) Must of us have homecooked object layers, we need to think hard how to
move forward
C) The poe kernel should have no concept of the object layer, multiple objet
layers must be able to exist. (Just like multiple kernels exist today)
D) If the poe kernel doesn't manage to transparantly move messages across
kernel bounderies the object level will not help, if you don't want to
reimplment kernel level code in your object layer.
Multiple layers GCing the same thing is an error prone approach.
Artur
