You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.fr> on 2013/04/23 11:38:52 UTC

Would like opinion about unmodifiable metadata

Hello all

We often need to build a metadata object, then declare it unmodifiable 
in order to allow the same metadata to be safely shared by many objects. 
For example one may create the following ResponsibleParty for their 
organization:

DefaultResponsibleParty myOrganization = new DefaultResponsibleParty();
myOrganization.setOrganisationName("My organization");
myOrganization.setContactInfo(...etc...);

then share the same ResponsiblyParty by many object, e.g. all citations 
toward data or documents produced by that organization. This is 
currently done by invoking the "freeze()" method on the metadata object.

The question is about what should be the behaviour toward child elements 
of the metadata one is freezing. In current implementation, when 
freezing a metadata, we clone all children and freeze those clones. The 
original child objects are left unchanged, which I though would avoid 
unexpected freezing if someone has keep reference to the children 
elsewhere. However when looking back to our experience, I don't think we 
have meet a case where this was useful. So the question is: should we 
change the behaviour and freeze all children directly, without cloning 
them? This would simplify a little bit the code but actually not that much.

     Martin


Re: Would like opinion about unmodifiable metadata

Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Chris

Le 23/04/13 16:27, Mattmann, Chris A (398J) a écrit :
> +1 to:
>
> freeze():
> for all child in children:
>     child.freeze()

Nice way to summarize the question :-)

Thanks, I will do that way.

     martin


Re: Would like opinion about unmodifiable metadata

Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
+1 to:

freeze():
for all child in children:
   child.freeze()

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++






-----Original Message-----
From: Martin Desruisseaux <ma...@geomatys.fr>
Organization: Geomatys
Reply-To: "dev@sis.apache.org" <de...@sis.apache.org>
Date: Tuesday, April 23, 2013 2:38 AM
To: Apache SIS <de...@sis.apache.org>
Subject: Would like opinion about unmodifiable metadata

>Hello all
>
>We often need to build a metadata object, then declare it unmodifiable
>in order to allow the same metadata to be safely shared by many objects.
>For example one may create the following ResponsibleParty for their
>organization:
>
>DefaultResponsibleParty myOrganization = new DefaultResponsibleParty();
>myOrganization.setOrganisationName("My organization");
>myOrganization.setContactInfo(...etc...);
>
>then share the same ResponsiblyParty by many object, e.g. all citations
>toward data or documents produced by that organization. This is
>currently done by invoking the "freeze()" method on the metadata object.
>
>The question is about what should be the behaviour toward child elements
>of the metadata one is freezing. In current implementation, when
>freezing a metadata, we clone all children and freeze those clones. The
>original child objects are left unchanged, which I though would avoid
>unexpected freezing if someone has keep reference to the children
>elsewhere. However when looking back to our experience, I don't think we
>have meet a case where this was useful. So the question is: should we
>change the behaviour and freeze all children directly, without cloning
>them? This would simplify a little bit the code but actually not that
>much.
>
>     Martin
>