> They currently do support 8.4 and I am planning to continue support;  > Even
> 8.0 I supported  >  > Any signs that they don't?
> 
> Not to my knowledge.
> 
> One
> reason I ask though is in consideration of the possibility of merging Tcl::pTk
> and Tcl::Tk, which I have not made progress on. Even if I leave in
> compatibility with 8.4, I might only be willing to "actively support" and test
> on 8.5 or later.

Good point

However even if Tcl::Tk will drop 8.4, Tcl.pm still should support it;

OTOH for now we should elaborate a plan of "merging" of Tcl::Tk and Tcl::pTk.

In my opinion, nowadays the picture is this:
- I see lots of "good" activity on github Tcl::pTk project; I pretty much like 
it
- however IMO there is some, say, 5% of incompatibilities, which will never go 
away,
  So if you take random perl/Tk program - will it just run, after you'll 
replace "use Tk" with "use Tcl::pTk"? mostly - no (correct me if I am wrong)
- but perlTk itself is "Tk-804.034" <-- it even mentions 8.4, which you 
intended to drop, so I see no very deep reason on having 100% compatibility. 
Syntax is good, but no more than that, 95 is enough (of course other people 
could have different opinion, I respect that other opinion)


Yet, there is another point:

Now Tcl::Tk is a single-file perl module, which fully allows perl-tk syntax; it 
is very tempting to have it single and thin and very lightweight.
For me, perl/Tk syntax is preferable (together with pure-tcl) over some perl/Tk 
module that I could potentially use.

To make both projects happy, I would think about following proposal:

- I will move that single file of current Tcl::Tk Tcl/Tk.pm into Tcl.pm, 
renamed somehow.
- ... which will be optionally called from Tcl, such as "use Tcl ':perltk';
- (while doing that I will remove lots of unneeded methods from there and will 
modernize it (no, this does not mean ''use warnings'' at all))
- then you could use Tcl::Tk namespace freely; merge and/or refer /or alias to 
each other; 

IDK whether this wins something, all these thoughts are fresh;

So perl/Tk syntax will be (optionally) provided by "tcl.pm"; no care of perl/tk 
compat at all.
This will mean Tcl::Tk in its current stage could leave and free space for 
better compatibility.

PS.
I must admit I haven't touched codebase of tcl.pm for several months already, 
but surely I am planning to return to this, soon :)

Reply via email to