Tcl Source Code

View Ticket
Login
Bounty program for improvements to Tcl and certain Tcl packages.
Ticket UUID: dd3b844fdabdeae5fcb07f4a16d1c62ae5fa75ac
Title: oo::copy needs an optional namespace parameter
Type: RFE Version:
Submitter: dkf Created on: 2016-11-23 21:42:28
Subsystem: 35. TclOO Package Assigned To: dkf
Priority: 5 Medium Severity: Minor
Status: Closed Last Modified: 2018-01-01 17:50:40
Resolution: Fixed Closed By: pooryorick
    Closed on: 2018-01-01 17:50:40
Description:

Background

I was talking to Nathan Coulter at the Tcl conference and he was telling me about some of the things that are done in Rivet and NaviServer to get speed. In particular, he was doing horrible things to try to clone a namespace; it was a significant bottleneck. I mentioned that TclOO can clone namespaces (imperfectly) and speculated that oo::copy might be a useful tool. And indeed it might, except that existing code requires that the created namespace have a particular name (::request if I remember right) and oo::copy doesn't allow specifying the name of the created namespace, even though the underlying C API for object copying (Tcl_CopyObjectInstance) does.

Feature Request

Add an extra optional argument to oo::copy to allow specifying the target object namespace. If omitted, the current behaviour should be used. If present, it must be in a form acceptable to Tcl_CreateNamespace and must not refer to an existing namespace; the name of the clone object's namespace will be the given value (instead of the default, arbitrary one). This will make oo::copy have two optional arguments, instead of the current single one.
oo::copy sourceObject ?targetObject? ?targetNamespace?

Implementation Notes

The basic functionality is already there at the C level; this is just exposing it to the Tcl level (and testing/documenting).

User Comments: pooryorick added on 2018-01-01 17:50:40:

See TIP 473 and Changes in Tcl/Tk 8.6.7.


dkf added on 2017-06-07 09:31:09:

It's not a single parameter because the object's command doesn't (usually) reside in its instance namespace, and they formally don't have a lot to do with each other.


avl42 (claiming to be avl) added on 2017-06-07 06:22:50:
Naive question: why not "targetNamespace::targetObject" as a single argument?

(disclaimer "I've got no idea what I'm talking about" applies.)