On Mon, Apr 20, 2015 at 3:42 AM, Nick Wellnhofer <[email protected]> wrote:
> Since we only support arrays of objects (pointers), uint32_t indices allow > for 32 GB arrays and 96 GB hash tables on 64-bit systems. On top of that, > you'll typically need much more memory to store the objects themselves. So I > don't see an immediate need for 64-bit indices. With strings, the limit of > 32-bit indices can be hit much earlier in practice. > > But it shouldn't be hard to implement 64-bit indices for all container > types. Maybe we should just go for it. +1 >> That would imply making Clone() shallow, and implementing deep copying as >> Deep_Clone(). > > Maybe we shouldn't offer deep cloning at all? Tim and I talked over your suggestion in the office. The conclusion we came to was that Clone() should be defined to provide shallow copy semantics, and deep cloning should be available via a specialized library function outside the core. > [1] Here are a couple of related things I always wondered about: > > Shouldn't we hide String, Array, and Hash completely from Perl? For the most > part, they already are invisible. Method return values and callback > arguments will always be converted. Only the constructor returns a Clownfish > object. I agree that they should at least be undocumented for the time being. I figure that access to those classes via the host should be an "expert" API because they are anomalous. I'm not sure what that expert API should look like just yet. There will definitely be times when somebody doesn't want to convert, though -- such as passing a gigantic data structure. > Why don't we implement more To_Host methods instead of the huge if/else > chain in XSBind_cfish_to_perl? I agree that that would be a good approach. It occurs to me that Hash and Array ought to be special, though: in order to guard against circular references and infinite recursion, they should dispatch to a helper routine which performs memoization a la the algo from Python's deepcopy. That will mean a performance hit because we'll need to create an extra hash table, but the safety is worth it. Marvin Humphrey
