On Mon, 05 Oct 2009, Konovalov, Vadim (Vadim)** CTR ** wrote: > > > > I put the bitmap files (i.e. the xbm, xpm, etc files) in the > > Tcl/Tk directory, because perl/tk puts them in a similar > > place. Bitmap files for perl/tk end up in the Tk directory > > after installation. They could possibly be moved to a bitmaps > > directory under the Tcl/Tk directory, as long a > > Tcl::Tk->findINC can still find them. > > we are not obliged to follow bad designs. findINC is bogus and it > should not be a reason for anything otherwise inconvenient.
You may want to take a look at File::ShareDir (and File::ShareDir::Install for MakeMaker installation support). > > > > If we separated out the perl/tk files, it could cause some > > confusion in converting from perl/tk code to Tcl::Tk. For > > example, the Font.pm package is currently in the Tcl/Tk > > directory, so it gets used with a "use Tcl::Tk::Font", which > > is very similar to the perl/tk sytax of "use Tk::Font". If > > the Font.pm package was moved to another directory (like > > "Tcl/Tk/perltk"), then you would have to use "use > > Tcl::Tk::perltk::Font". > > Would the "Tcl::pTk::Font" be reasonalble alternative? > > This may be problematic with CPAN indexing, I wonder, are there any > modules that do something like this? On the one side, the "Tcl" name > space is likely to be free for our usage, but on the other hand such a > pollution to another namespace could be prohibited. I don't think using different namespaces based on the codes heritage is a good idea. Namespaces should be chosen that make the most sense from the *users* perspective. Why would the user care that the Font class *implementation* was somehow inherited from the old PerlTk package and not written from scratch for Tcl::Tk? You can organize your source code in the distribution into multiple directories (and uses multiple Makefile.PLs to build them and install them into the correct location), but that is still nothing that the end user should need to worry about. Cheers, -Jan
