I guess I don't see how this helps. Modifying the existing Tcl::Tk to be a hash-based object is about 1% of the changes needed.
Subclassing from this updated Tcl::Tk for a new Tcl::pTk package wouldn't be worth it because you would be basically overloading all the methods. It would make more sense for Tcl::pTk to subclass directly from Tcl.pm, just like Tcl::Tk does now. -John On Sat, May 15, 2010 at 10:46 AM, Konovalov, Vadim (Vadim)** CTR ** <vadim.konova...@alcatel-lucent.com> wrote: >> From: John Cerney [mailto:john.cer...@gmail.com] > >> It looks like the changes I have made don't really fit into your >> vision for where the Tcl::Tk package should go. It probably makes more >> sense for me to release the changes as a separate package (probably >> named Tcl::pTk) as I mentioned earlier. I hope you can support that. > > I am not the only one who decides, and I think the idea of yet another same > module would be considered as not a good one, unfortunately. > > I propose following approach - I'll change Tcl/Tk.pm to have a hash-based > object, so it will be compatible with your other compatibility part, and then > I will release it as next release. > Then, we could decide on how to apply next. > > So this will hopefully allow to move forward. > > Regards, > Vadim.
