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 use of immutable value object/interfaces [Re: [Axis2] OM API review/changes
Date Fri, 22 Oct 2004 00:14:47 GMT
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


Mime
View raw message