Samisa, That is an ideal solution in testing this and getting our implementations straight, without ever having to worry about side effects. +1
Regards, Senaka > [EMAIL PROTECTED] wrote: >> Dinesh, you are right that one can develop a cloning algorithm that >> defers any copying until the object is modified, a copy-on-write >> algorithm. But such an algorithm would depend on knowing that ref >> counts are used only for cloning. Given this assumption, when the ref >> count was greater than one, the code could choose to copy an instantiate >> a new instance of the object when it was modified. >> >> I don't think that assumption is met today. I see ref counts >> implemented currently for attributes and namespaces, and not for >> elements or text. In particular, for attributes, this allows the user >> of axiom to create an attribute one time, and attach it to several >> elements as needed. And it could be that this user wants the ability to >> change the attribute value once and have the modification apply to all >> the elements that share it. >> >> Now maybe this is a capability that was not foreseen and is not >> supported, but it exists nonetheless. So one cannot implement a >> copy-on-write algorithm without risking breaking existing code. >> > > Given the chances of breaking the existing - shall we do this change on > a temporary branch, rather than on the svn head? > > This way, we have more room for taking risks and fixing breaks. > > Thanks, > Samisa... > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
