On Wed, Oct 7, 2009 at 3:12 AM, Konovalov, Vadim (Vadim)** CTR ** <vkonova...@alcatel-lucent.com> wrote: > > > 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. >
Ok > > > > 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. > I was thinking of a programmer that was coming from the perl/tk world. As long as the Tcl::Tk package worked like perl/tk, I don't think they would care whether a .pm file came from perl/tk or it was coded from scratch to work. > > > > 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. If someone accidentally replaces a file with a perl/tk file (for example replaced the lib/Tcl/Tk/Font.pm with the Font.pm from the perl/tk distribution), one or more test cases would fail pretty spectacularly (like t/font.t, t/font2.t, etc). This is one of the nice things about having a comprehensive test suite. > > > > > 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. > I thought about doing something like this originally; Having a directory that contained unmodified perl/tk files, with a set of patches and scripts that would auto-modify the files for Tcl::Tk and move them to the proper locations. At the time, it didn't seem worth it because 1) Added complexity in the Makefile.PL to perform all the patching 2) Would need a working patch program, which is ok for linux/unix, but probably not a good assumption for windows. 3) Marginal benefit, considering how often perl/tk is updated. If perl/tk was being updated every few months, and we needed to stay in sync, it would really pay to have a Tcl::Tk patch system like this. But the last tk update was two years ago, and there is some doubt how much it is going to be updated in the future, given the original author is deceased. Maybe this needs to be revisited. > > > 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. > Ok > > > 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. > I am not a big proponent of rigid coding standards, but I have seen this one in a few places. It also has been included in the PerlCritic package ( http://search.cpan.org/~elliotjs/Perl-Critic-1.105/lib/Perl/Critic/Policy/Modules/ProhibitMultiplePackages.pm ) > 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. > I don't mean to argue semantics, but by "Ready for Release", I meant ready for the release process. Normally as part of the release process, I do things like like update version numbers, change history, manifest and then upload to CPAN. > (PS - not strictly a requirement, but a small wish - can you send e-mail in > plaintext format? TIA!) > Hopefully this mail is plaintext. -John
