You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Aleksander Slominski <as...@cs.indiana.edu> on 2004/10/22 02:14:47 UTC
use of immutable value object/interfaces [Re: [Axis2] OM API review/changes
Sanjiva Weerawarana wrote:
>"Aleksander Slominski" <as...@cs.indiana.edu> writes:
>
>
>>i agree that API should be easy to use but we need to strive for a
>>balance and be careful to have necessary methods to make API easy to
>>use (but not too many) and to allow use of immutable objects that can
>>be shared (such as the same namespace) between multiple elements leading
>>to lower memory usage.
>>
>>
>
>I'm confused .. we obviously need to create the OM too. Are we
>talking about disallowing one to *modify* an already created tree
>instead of about having methods to create a new OM?
>
>
no that is nto what i meant.
i though about case of tree (OMElement) that is container of objects
where some of those objects are immutable (like namespaces or attributes).
so if you need to change element namespace or attribute just create new
one and replace element namespace or attribute.
exactly the same reasoning goes for immutability of String (including
multi-thread safety for sharing, caching, low memory usage etc.) and for
more detailed rationale for immutable "value" object please read (better
explained that i can):
http://www-106.ibm.com/developerworks/java/library/j-jtp02183.html
>If so I'm ok with having the OM be immutable at least initially.
>
>
i was not proposing anyting that radical - i think OMElement should be
mutable only OMNamespace, OMAttribute should be immutable (and maybe
OMComment).
>That should give us maximum performance and if you really want
>to modify the OM then you have to re-generate it. That may bite
>us badly when dealing with encrypted headers but we can delay
>that a bit I think. (Decryption will be so slow that creating
>a new OM will not be a problem :)) However, we should be able
>to re-parent OM nodes I think.
>
>
that would be interesting: to have read-only API, copy-on-write API and
full read-write API subsets that are selectable as required by and
described in metadata of handlers ...
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: use of immutable value object/interfaces [Re: [Axis2] OM API
review/changes
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Ajith Ranabahu wrote:
>Hi,
>How I see this mutable/immutable thing is this.
>If we make an object immutable we are done with making changes to it.
>The only option we have if we are not happy with the values that are
>inside the immutable object is to make a new one with the correct
>values and replace the earlier one.
>
>
that is correct.
>As far as an XML document structure is concerned, having to create a
>whole new element when a change is needed seems ridiculous (since it
>is quite frequent).
>
i agree :)
>by contrast namespaces stay unchanged through the
>scope of the document and are good candidates for being immutable
>objects.
>
>
yes
>Hopefully this is the essence of the concept of mutable/immutable.
>Please correct me if I am wrong.
>
>
sounds correct to me.
>When our OM is concerned, I tend to put only OMNamespace as immutable.
>An attribute doesn't seems to be that much convincing as an immutable
>object to me.
>
>
i have just searched heavy XML message/XML schemas/WSDL manipulating
code (Xydra
<http://www.extreme.indiana.edu/viewcvs/%7Echeckout%7E/mgc/xydra/>) and
did not find *any* example where attribute value were changed instead
most code was about finding attributes/values and adding new attributes ...
alek
>
>
>>On Fri, 22 Oct 2004 09:27:24 +0600, Eran Chinthaka
>><ch...@opensource.lk> wrote:
>>
>>
>>
>>Alek's idea of making OMElement mutable and others immutable seems
>>interesting.
>>
>>
>>
>>Shall we talk about this in use cases perpectives ???
>>
>>
>>
>>What are the things we do for the soap message within the engine ??
>>
>>
>>
>>1. need to access the headers. What we basically do here is that mostly
>>read the contents of the headers. And sometime may remove and add new
>>headers. Plus we may modify Element, Texts, Attributes. But I think we
>>rarely do modifications to comments or namespaces. In this regard, making
>>OMElement mutable make sense, but I would say that Attributes are highly
>>subjected to modifications. So making OMAttributes also mutable seems good.
>>But I agree in making rest of the things immutable.
>>
>>2. If u think about the body, in current situations this will be accessed
>>only by either Security handlers or by the provider. (If this is not
>>correct, I like to see a *use case*, where someone need to access the body).
>>Provider of course, it needs to just read the contents of the body. SO there
>>are no modifications to the body.
>>
>>As Sanjiva said, we can forget the performance discussion about the
>>supporting of security.
>>
>>
>>
>>So in conclusion, I think following seems to be ok, for the time being.
>>
>>
>>
>>OMElement, OMAttribute – mutable
>>
>>OMNamespace, OMText (or String) – immutable.
>>
>>
>>
>>Plus I also agree with the idea of "to allow use of immutable objects that
>>can be shared (such as the same namespace) between multiple elements leading
>>to lower memory usage."
>>
>>
>>
>>
>>
>>Comments …………… ?
>>
>>
>>
>>________________________________
>>
>>
>>
>>Eran Chinthaka
>>
>>Lanka Software Foundation
>>
>>
>>
>>
>>
>>
>>
>>>-----Original Message-----
>>>
>>>
>>>From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
>>>
>>>
>>>Sent: Friday, October 22, 2004 6:15 AM
>>>
>>>
>>>To: axis-dev@ws.apache.org
>>>
>>>
>>>Cc: chintaka@opensource.lk
>>>
>>>
>>>Subject: use of immutable value object/interfaces [Re: [Axis2] OM API
>>>
>>>
>>>review/changes
>>>
>>>
>>>Sanjiva Weerawarana wrote:
>>>
>>>
>>>>"Aleksander Slominski" <as...@cs.indiana.edu> writes:
>>>>
>>>>
>>>>>i agree that API should be easy to use but we need to strive for a
>>>>>
>>>>>
>>>>>balance and be careful to have necessary methods to make API easy to
>>>>>
>>>>>
>>>>>use (but not too many) and to allow use of immutable objects that can
>>>>>
>>>>>
>>>>>be shared (such as the same namespace) between multiple elements leading
>>>>>
>>>>>
>>>>>to lower memory usage.
>>>>>
>>>>>
>>>>I'm confused .. we obviously need to create the OM too. Are we
>>>>
>>>>
>>>>talking about disallowing one to *modify* an already created tree
>>>>
>>>>
>>>>instead of about having methods to create a new OM?
>>>>
>>>>
>>>no that is nto what i meant.
>>>
>>>
>>>i though about case of tree (OMElement) that is container of objects
>>>
>>>
>>>where some of those objects are immutable (like namespaces or attributes).
>>>
>>>
>>>so if you need to change element namespace or attribute just create new
>>>
>>>
>>>one and replace element namespace or attribute.
>>>
>>>
>>>exactly the same reasoning goes for immutability of String (including
>>>
>>>
>>>multi-thread safety for sharing, caching, low memory usage etc.) and for
>>>
>>>
>>>more detailed rationale for immutable "value" object please read (better
>>>
>>>
>>>explained that i can):
>>>
>>>
>>>http://www-106.ibm.com/developerworks/java/library/j-jtp02183.html
>>>
>>>
>>>>If so I'm ok with having the OM be immutable at least initially.
>>>>
>>>>
>>>i was not proposing anyting that radical - i think OMElement should be
>>>
>>>
>>>mutable only OMNamespace, OMAttribute should be immutable (and maybe
>>>
>>>
>>>OMComment).
>>>
>>>
>>>>That should give us maximum performance and if you really want
>>>>
>>>>
>>>>to modify the OM then you have to re-generate it. That may bite
>>>>
>>>>
>>>>us badly when dealing with encrypted headers but we can delay
>>>>
>>>>
>>>>that a bit I think. (Decryption will be so slow that creating
>>>>
>>>>
>>>>a new OM will not be a problem :)) However, we should be able
>>>>
>>>>
>>>>to re-parent OM nodes I think.
>>>>
>>>>
>>>that would be interesting: to have read-only API, copy-on-write API and
>>>
>>>
>>>full read-write API subsets that are selectable as required by and
>>>
>>>
>>>described in metadata of handlers ...
>>>
>>>
>>>thanks,
>>>
>>>
>>>alek
>>>
>>>
>>>--
>>>
>>>
>>>The best way to predict the future is to invent it - Alan Kay
>>>
>>>
>>
>>
>>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: use of immutable value object/interfaces [Re: [Axis2] OM API review/changes
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi,
How I see this mutable/immutable thing is this.
If we make an object immutable we are done with making changes to it.
The only option we have if we are not happy with the values that are
inside the immutable object is to make a new one with the correct
values and replace the earlier one.
As far as an XML document structure is concerned, having to create a
whole new element when a change is needed seems ridiculous (since it
is quite frequent). by contrast namespaces stay unchanged through the
scope of the document and are good candidates for being immutable
objects.
Hopefully this is the essence of the concept of mutable/immutable.
Please correct me if I am wrong.
When our OM is concerned, I tend to put only OMNamespace as immutable.
An attribute doesn't seems to be that much convincing as an immutable
object to me.
Ajith
>On Fri, 22 Oct 2004 09:27:24 +0600, Eran Chinthaka
><ch...@opensource.lk> wrote:
>
>
>
> Alek's idea of making OMElement mutable and others immutable seems
> interesting.
>
>
>
> Shall we talk about this in use cases perpectives ???
>
>
>
> What are the things we do for the soap message within the engine ??
>
>
>
> 1. need to access the headers. What we basically do here is that mostly
> read the contents of the headers. And sometime may remove and add new
> headers. Plus we may modify Element, Texts, Attributes. But I think we
> rarely do modifications to comments or namespaces. In this regard, making
> OMElement mutable make sense, but I would say that Attributes are highly
> subjected to modifications. So making OMAttributes also mutable seems good.
> But I agree in making rest of the things immutable.
>
> 2. If u think about the body, in current situations this will be accessed
> only by either Security handlers or by the provider. (If this is not
> correct, I like to see a *use case*, where someone need to access the body).
> Provider of course, it needs to just read the contents of the body. SO there
> are no modifications to the body.
>
> As Sanjiva said, we can forget the performance discussion about the
> supporting of security.
>
>
>
> So in conclusion, I think following seems to be ok, for the time being.
>
>
>
> OMElement, OMAttribute – mutable
>
> OMNamespace, OMText (or String) – immutable.
>
>
>
> Plus I also agree with the idea of "to allow use of immutable objects that
> can be shared (such as the same namespace) between multiple elements leading
> to lower memory usage."
>
>
>
>
>
> Comments …………… ?
>
>
>
> ________________________________
>
>
>
> Eran Chinthaka
>
> Lanka Software Foundation
>
>
>
>
>
> > -----Original Message-----
>
> > From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
>
> > Sent: Friday, October 22, 2004 6:15 AM
>
> > To: axis-dev@ws.apache.org
>
> > Cc: chintaka@opensource.lk
>
> > Subject: use of immutable value object/interfaces [Re: [Axis2] OM API
>
> > review/changes
>
> >
>
> > Sanjiva Weerawarana wrote:
>
> >
>
> > >"Aleksander Slominski" <as...@cs.indiana.edu> writes:
>
> > >
>
> > >
>
> > >>i agree that API should be easy to use but we need to strive for a
>
> > >>balance and be careful to have necessary methods to make API easy to
>
> > >>use (but not too many) and to allow use of immutable objects that can
>
> > >>be shared (such as the same namespace) between multiple elements leading
>
> > >>to lower memory usage.
>
> > >>
>
> > >>
>
> > >
>
> > >I'm confused .. we obviously need to create the OM too. Are we
>
> > >talking about disallowing one to *modify* an already created tree
>
> > >instead of about having methods to create a new OM?
>
> > >
>
> > >
>
> > no that is nto what i meant.
>
> >
>
> > i though about case of tree (OMElement) that is container of objects
>
> > where some of those objects are immutable (like namespaces or attributes).
>
> > so if you need to change element namespace or attribute just create new
>
> > one and replace element namespace or attribute.
>
> >
>
> > exactly the same reasoning goes for immutability of String (including
>
> > multi-thread safety for sharing, caching, low memory usage etc.) and for
>
> > more detailed rationale for immutable "value" object please read (better
>
> > explained that i can):
>
> > http://www-106.ibm.com/developerworks/java/library/j-jtp02183.html
>
> >
>
> > >If so I'm ok with having the OM be immutable at least initially.
>
> > >
>
> > >
>
> > i was not proposing anyting that radical - i think OMElement should be
>
> > mutable only OMNamespace, OMAttribute should be immutable (and maybe
>
> > OMComment).
>
> >
>
> > >That should give us maximum performance and if you really want
>
> > >to modify the OM then you have to re-generate it. That may bite
>
> > >us badly when dealing with encrypted headers but we can delay
>
> > >that a bit I think. (Decryption will be so slow that creating
>
> > >a new OM will not be a problem :)) However, we should be able
>
> > >to re-parent OM nodes I think.
>
> > >
>
> > >
>
> > that would be interesting: to have read-only API, copy-on-write API and
>
> > full read-write API subsets that are selectable as required by and
>
> > described in metadata of handlers ...
>
> >
>
> > thanks,
>
> >
>
> > alek
>
> >
>
> > --
>
> > The best way to predict the future is to invent it - Alan Kay
>
> >
>
>
--
Ajith Ranabahu
RE: use of immutable value object/interfaces [Re: [Axis2] OM API review/changes
Posted by Eran Chinthaka <ch...@opensource.lk>.
Alek's idea of making OMElement mutable and others immutable seems
interesting.
Shall we talk about this in use cases perpectives ???
What are the things we do for the soap message within the engine ??
1. need to access the headers. What we basically do here is that mostly
read the contents of the headers. And sometime may remove and add new
headers. Plus we may modify Element, Texts, Attributes. But I think we
rarely do modifications to comments or namespaces. In this regard, making
OMElement mutable make sense, but I would say that Attributes are highly
subjected to modifications. So making OMAttributes also mutable seems good.
But I agree in making rest of the things immutable.
2. If u think about the body, in current situations this will be accessed
only by either Security handlers or by the provider. (If this is not
correct, I like to see a *use case*, where someone need to access the body).
Provider of course, it needs to just read the contents of the body. SO there
are no modifications to the body.
As Sanjiva said, we can forget the performance discussion about the
supporting of security.
So in conclusion, I think following seems to be ok, for the time being.
OMElement, OMAttribute - mutable
OMNamespace, OMText (or String) - immutable.
Plus I also agree with the idea of "to allow use of immutable objects that
can be shared (such as the same namespace) between multiple elements leading
to lower memory usage."
Comments ..... ?
________________________________
Eran Chinthaka
Lanka Software Foundation
> -----Original Message-----
> From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
> Sent: Friday, October 22, 2004 6:15 AM
> To: axis-dev@ws.apache.org
> Cc: chintaka@opensource.lk
> Subject: use of immutable value object/interfaces [Re: [Axis2] OM API
> review/changes
>
> Sanjiva Weerawarana wrote:
>
> >"Aleksander Slominski" <as...@cs.indiana.edu> writes:
> >
> >
> >>i agree that API should be easy to use but we need to strive for a
> >>balance and be careful to have necessary methods to make API easy to
> >>use (but not too many) and to allow use of immutable objects that can
> >>be shared (such as the same namespace) between multiple elements leading
> >>to lower memory usage.
> >>
> >>
> >
> >I'm confused .. we obviously need to create the OM too. Are we
> >talking about disallowing one to *modify* an already created tree
> >instead of about having methods to create a new OM?
> >
> >
> no that is nto what i meant.
>
> i though about case of tree (OMElement) that is container of objects
> where some of those objects are immutable (like namespaces or attributes).
> so if you need to change element namespace or attribute just create new
> one and replace element namespace or attribute.
>
> exactly the same reasoning goes for immutability of String (including
> multi-thread safety for sharing, caching, low memory usage etc.) and for
> more detailed rationale for immutable "value" object please read (better
> explained that i can):
> http://www-106.ibm.com/developerworks/java/library/j-jtp02183.html
>
> >If so I'm ok with having the OM be immutable at least initially.
> >
> >
> i was not proposing anyting that radical - i think OMElement should be
> mutable only OMNamespace, OMAttribute should be immutable (and maybe
> OMComment).
>
> >That should give us maximum performance and if you really want
> >to modify the OM then you have to re-generate it. That may bite
> >us badly when dealing with encrypted headers but we can delay
> >that a bit I think. (Decryption will be so slow that creating
> >a new OM will not be a problem :)) However, we should be able
> >to re-parent OM nodes I think.
> >
> >
> that would be interesting: to have read-only API, copy-on-write API and
> full read-write API subsets that are selectable as required by and
> described in metadata of handlers ...
>
> thanks,
>
> alek
>
> --
> The best way to predict the future is to invent it - Alan Kay
>