Please make sure that you reply to the mailing list. On Thu, 2009-07-23 at 22:48 +0800, Bo Yang wrote: > >> Generally, a resource manager is used to alloc/dealloc memory and > >> intern strings. In the now implementation, the dom_document itself is > >> both a Document and a resource manager. I think it is better to > >> separate the resource management function out of the Document and make > >> it a single object as resource_manager. > > > > Well, all allocation (aside from DocumentType nodes) occurs in the > > context of a document. Thus, by definition, the Document has to manage > > resources. It doesn't really make sense to me to have separate resource > > management objects floating around. > > So, how about just keep the resource_manager here, and in the future > of DOM, if there is indeed no need of it, I will remove it. Anymore, > removing is more simple than adding one. :)
I still don't like it, but fine. > >> I am sorry but I did not realize why a single static allocator is not > >> enough. > > > > Is it possible for there to be multiple DOMImplementations? If so, then > > a static allocator simply won't work. > > I can't see the need for multiple DOMImplementations for now. If so, > changing the code then is ok, I think. Right. That clears up most of the issues, then. Please document that DOMImplementation is a singleton so I don't get confused in future. > >> If the client has a lwc_string * and want to call our API which take a > >> dom_string, this function is very helpful for that situation and it is > >> a common situation. > > > > That doesn't explain why dom_document_create_lwcstring() is in the > > public API. > > Ah, the client can call this API to create a dom_string from a > lwc_string within the context of some document. It is a convenient and > useful API for clients of DOM. I don't think so. The client will already know what the context is -- they passed it to the Document after all. > >> I think our clients may need to test whether two NodeMap are equal. > >> Such as in JS. > > > > Would they not just perform simple equality checking -- i.e. comparing > > the objects' addresses in memory? > > In the implementation of NamedNodeMap now, two Map may equals even if > they are different objects. Only if you're wanting member-wise equality, no? > >> There is only one place where I need to clone a hash_table, so I put > >> it here. You are right it is in the hash_table, but putting it here is > >> simple, because the Element now what is the key and value in the > >> hash_table. > > > > I disagree. It should be a generic function within hashtable.c. > > > > Something like: > > > > struct hash_table *hash_clone(struct hash_table *hash, > > dom_alloc alloc, void *alloc_pw, > > void *(*clone_key)(void *key, void *pw, > > dom_alloc alloc, void *alloc_pw), > > void *key_pw, > > void *(*clone_value)(void *value, void *pw, > > dom_alloc alloc, void *alloc_pw), > > void *value_pw); > > > > Ok, although the function is rather complex, I will change it. You'd typedef the function pointers, of course. J.
