On 22/04/2015 06:14, Marvin Humphrey wrote:
On Mon, Apr 20, 2015 at 3:42 AM, Nick Wellnhofer <[email protected]> wrote:
But it shouldn't be hard to implement 64-bit indices for all container
types. Maybe we should just go for it.
+1
OK, I'll work on that:
https://issues.apache.org/jira/browse/CLOWNFISH-35
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
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.
Yes, we should support this at some point. This also goes the other way. It
would be nice to pass host language objects like string, arrays, or hashes to
Clownfish without cloning. I'm not sure about the best way to solve this, though.
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.
+1, I created an issue:
https://issues.apache.org/jira/browse/CLOWNFISH-36
Nick
