> From: John Cerney [mailto:john.cer...@gmail.com] > On Tue, Oct 6, 2009 at 1:01 AM, Konovalov, Vadim (Vadim)** > CTR ** <vkonova...@alcatel-lucent.com> wrote:
> Yeah, findINC is annoying, but it is used in a lot of perl/tk > modules and demo code. I think it still has to be supported > for perl/tk compatibility at some level. findINC is in Tcl::Tk for a long time already. If you need to be updated to include a special path for Tk-derived grpahic - ok, we could extend it. > > Other than the bitmap files (which I think can be put in a > separate directory with no problems), I think any changes in > the .pm file locations is going to cause confusion to the > end-user, who probably doesn't care about the history of the > files included (i.e. whether they were modified from perl/tk > or coded from scratch). which end user you have in mind? those who write programs, should not notice that perl/Tk-derived files are collected in some hidden place. On the contrary, if ./site/lib//Tcl/Tk/ directory will contain random perl/Tk files inside it, this could cause confusion. > > Is there any other issue with having the perl/tk derived > files in the same directory as the Tcl::Tk original files? yes, someone will see that this is the same file and will replace it accidentially from the unmodified one from perlTk code base. The findINC will find wrong PM, because it is also in @INC. that said, this would be a source for a hidden hard-to-find bugs. > > From a software maintenance standpoint, I can see that you > would want to know, so you could make any bug-fixes made to > the perl/tk codebase also in the Tcl::Tk codebase. Other than > that, is there some other reason why you want the files separated? This reason is already strong enough to keep them separated. perl/Tk codebase is a huge mess, so careful selecting and then describing the borrowed files to add is a must. And perl/Tk files they should be in their own corner. Including graphics. I even think that files borrowed from perl/Tk should be placed unmodified and there should be a patch script which brings such files to the Tcl::Tk compatibility. > Perl/Tk definitely has a mess of files. I think the biggest > mess there is the duplication and modification of the Tcl/Tk > C-code. Using your Tcl::Tk package, I think we can provide > almost 100% compatibility with a lot of existing perl/tk code > out there without having to include and compile modified > Tcl/Tk c-code like perl/tk does. > > There has been a lot of .pm files added to achieve perl/tk > compatibility (including pure perl megawidget support). > Believe me, I didn't add anything extra that wasn't required > for the task. that is a great achievement. A huge advantage - to run perl/Tk code unmodified. I will look into the code more closely at weekend. > With the extra code added to the Tk.pm module, it was getting > really big and hard to manage so I split-out the Widget > package to a separate file. Also, most perl coding standards > I have seen try to avoid putting more than one package into a > single .pm file (usually one package = one file is preferred). I don't know of such coding standard. I know there are TIMTOWTDI and KISS, maybe there are more... I am sure a file could perfectly well contain a number of packages. What I do dislike - is blindly inserting "use strict" and whitespace reorganization. Ok, as I said, I'll look into the code later. Meanwhile, you must understand that the subject line "Tcl::Tk Updates Ready for Release" is currently not correct: the MANIFEST isn't right, there are file reorganizations needed, there's no update to history files, etc. (PS - not strictly a requirement, but a small wish - can you send e-mail in plaintext format? TIA!) Regards, Vadim.
