Regarding object pooling: What you describe is exactly one of the use cases where one should *not* use object pooling. Incremental collectors are very good at disposing short-lived objects without any noticeable pauses, so unless you are doing heavy resource acquisition on object creation, don't do pooling. This only leads to a heavier load on the GC, can easily lead to space leaks, and in general a good pooling strategy is not that easy as it might sound. If your program's performance is really, really bound by object creation, an ugly, but more promising route is to go "the imperative way", avoiding object creation as much as possible and mutating objects like hell. But in general that means restructuring your program, which might be hard, so I would only do this when I'm totally sure about the bottlenecks.
Regarding property types: I very much doubt that there are clean use cases of a "flexible API", where some property values are set in the constructor and some later. Things like this are a strong hint that the API has a flaw, and leads to obscure rules like "Don't call the foo function before bar and baz have been called on the object". Break down the objects/classes/..., and this becomes a non-problem. Cheers, S. -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
