Re: copy of JMI extents

Martin, thanks for your answer.

On Tue, Aug 06, 2002 at 03:36:19PM +0200, Martin Matula wrote:
> no, we don't have this functionality yet. It would be cool if you could 
> implement it as a utility that anyone can reuse.

Seems as if I have to. I'm going to write static copy methods. It will
be up to you to decide if and how to host the code, if you want to do
so. If you do not like static methods you can easily refactor the code
according to your gusto.

> Regarding the default factory methods it is not that simple. Consider 
> the case when the attribute holding the structure is readonly - then 
> there is no way of setting this attribute later.

What a pity !

> However I think that you can forget about this complicated situation
> with cyclic references, although it currently does not break any MOF
> constraints (as it is not really a composition), for JMI it has the
> same consequences as if it was a composition

Why does it have the same consequences for JMI as if it was a
composition ?

> so I guess that the fact that this is possible is just a hole in the
> spec

That means you propose to extend the MOF spec in a way such that
objects nested in structures or collections are treated as owned by
the owner of the attribute ? That would simplify a lot. Please forward
this proposal to the MOF working group.

> (IMO it is not solvable without breaking semantics of structures defined 
> in JMI saying that structures are immutable).

Really: copying cyclic references via read-only attributes would not
be possible. But that is not a problem: they cannot be copied, because
they cannot be set. But if they cannot be set, they never will be
there, hence no need to copy them ;-)

Your remarks make me follow this approach: Whenever I have to create a
target object, I will create it with all attributes given. Whenever a
source attribute value to be copied is or contains source objects, I
will copy them first. Whenever I detect a cycle, I will report an
error "cyclic attribute references not allowed by future MOF version".

-- 
Holger Krug
[email protected]