axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: use of immutable value object/interfaces [Re: [Axis2] OM API review/changes
Date Fri, 22 Oct 2004 04:22:39 GMT
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
>><chintaka@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" <aslom@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


Mime
View raw message