tcl-core

[TCLCORE] End of Votes

[Donal K. F. <don...@ma...>]

The following TIP CFVs have now closed:

#329: Try/Catch/Finally syntax
  Accepted 3/0/1
  For: DKF, JE, JN
  Against: none
  Present: KBK

#339: Case-Insensitive Package Names
  Rejected 2/4/0
  For: AK, JH
  Against: JE, JN, KBK, DGP
  Present: none
  RejectionReason: Breakage for existing code too great.

#343: A Binary Specifier for [format/scan]
  Accepted 4/1/0
  For: DKF, AK, JN, KBK
  Against: DGP
  Present: none
  Notes: Must only proceed with %b specifier, and not changes to other
         parts of [format] and [scan].

Thanks to everyone who voted. (I'm sorry I didn't vote on #339, but it
would have been a PRESENT...)

Dona.

Re: [TCLCORE] End of Votes

[Jeff H. <je...@ac...>]

On 12/10/08 5:18 AM, Donal K. Fellows wrote:
> #339: Case-Insensitive Package Names
>    Rejected 2/4/0
>    For: AK, JH
>    Against: JE, JN, KBK, DGP
>    Present: none
>    RejectionReason: Breakage for existing code too great.

And I'm annoyed again after finding another uselessly cased package. 
What moron named a package TclOO?  Ugh?!  Something will need to be done 
about this, and it will be done in ActiveTcl if not the core.

Jeff

Re: [TCLCORE] End of Votes

[Jan N. <jan...@gm...>]

2008/12/11 Donal K. Fellows <don...@ma...>:
> (I also quite like Jan's idea of
> old packages providing themselves twice, but I'm not deeply versed in
> the details enough to know if there are any gotchas that might arise.)

No there aren't any gotchas, and yes I am deeply versed in the details! :-)

> The case of the "TclOO" name itself in scripts is of great unimportance
> to me. If everyone wants it lower, that's fine: I'll make it happen.

It's not worth the trouble to change existing scripts, therefore I would
prefer to provide both "TclOO" and either "tcloo" or "oo" (or all three
of them, but I think two alternatives are sufficient).

Given that the core provides both "tcltest" and "Tcltest" - one being
for internal use only, I wouln't change that either, so "Tktest" should
be left as is. The only gotcha is that extensions cannot use the "tcl"
, "tk" or "oo"/"tcloo" (whatever we choose) packages any more, I
think that's more than acceptible.

How strict is the deadline supplying TIP's?

Regards,
          Jan Nijtmans

Re: [TCLCORE] End of Votes

[Jan N. <jan...@gm...>]

2008/12/11 Jeff Hobbs <je...@ac...>:
> And I'm annoyed again after finding another uselessly cased package.
> What moron named a package TclOO?  Ugh?!  Something will need to be done
> about this, and it will be done in ActiveTcl if not the core.

Something can be done about it: I think it would be good that the TCT
starts recommending all lower-case package names. That means that
TclOO should become tcloo (or maybe simply just "oo"), Tcl
should become tcl and Tk should become tk. Providing
compatibility is easy. (For TclOO it is not really an issue,
but because it is available as a separate package
as well, I would do it anyway.)

How about a mini-TIP, which simply proposes to recommend (but not
require) all-lowercase package names. Then the core should do the
same, just do "package provide"  twice, once with the original name,
once with the all-lowercase name. It's zero risk, and still allows
us to come with a better solution in Tcl 8.7.

Here is a patch doing this for Tk (unix and win). I think it
requires a mini-TIP, but I would be in favour of that.

Regards,
        Jan Nijtmans

Re: [TCLCORE] End of Votes

[<dg...@ni...>]

Quoting "Jan Nijtmans" <jan...@gm...>:
> Something can be done about it: I think it would be good that the TCT
> starts recommending all lower-case package names.

Thanks for raising this a second time.  Sometimes it takes
a few encounters to see the value of an idea.  I think this
is basically the right idea...

> Here is a patch doing this for Tk (unix and win).

...the good news is there's a much simpler way to accomplish
it that will involve only changes to Tcl itself.  I'll post
the sketch of that in a separate message with a new subject.

DGP

Re: [TCLCORE] End of Votes

[Donal K. F. <don...@ma...>]

Jeff Hobbs wrote:
> And I'm annoyed again after finding another uselessly cased package. 
> What moron named a package TclOO?  Ugh?!  Something will need to be done 
> about this, and it will be done in ActiveTcl if not the core.

Speaking as one of the morons :-) I don't like case sensitivity in
package names (it's “TclX” that causes me problems) and I certainly
think that we should be twisting people's arms to stick to lower-case in
future. I think sub-packages work better for public/private separation,
and don't have the nasties on Windows. (I also quite like Jan's idea of
old packages providing themselves twice, but I'm not deeply versed in
the details enough to know if there are any gotchas that might arise.)

The case of the “TclOO” name itself in scripts is of great unimportance
to me. If everyone wants it lower, that's fine: I'll make it happen.

Donal.

Re: [TCLCORE] End of Votes

[Steve L. <st...@di...>]

On 11/12/2008, at 6:14 PM, Donal K. Fellows wrote:

> Jeff Hobbs wrote:
>> And I'm annoyed again after finding another uselessly cased package.
>> What moron named a package TclOO?  Ugh?!  Something will need to be  
>> done
>> about this, and it will be done in ActiveTcl if not the core.
>
> Speaking as one of the morons :-) I don't like case sensitivity in
> package names (it's “TclX” that causes me problems) and I certainly
> think that we should be twisting people's arms to stick to lower- 
> case in
> future. I think sub-packages work better for public/private  
> separation,
> and don't have the nasties on Windows. (I also quite like Jan's idea  
> of
> old packages providing themselves twice, but I'm not deeply versed in
> the details enough to know if there are any gotchas that might arise.)
>
> The case of the “TclOO” name itself in scripts is of great  
> unimportance
> to me. If everyone wants it lower, that's fine: I'll make it happen.

I'm also reminded that if people are averse to breaking scripts, then  
there is a precedent in the strict package versioning introduced in 8.5.

Not trying to be contentious, just pointing out that on at least one  
previous occasion breakage was considered acceptable to enforce "the  
right approach", and that surely had more significant impact than what  
was proposed and rejected in TIP #339.

Steve

Re: [TCLCORE] End of Votes

[Donal K. F. <don...@ma...>]

Jan Nijtmans wrote:
> How strict is the deadline supplying TIP's?

Strict, unless there's a very good reason otherwise. (If we're not 
strict, we'll never do a release...)

Donal.

Re: [TCLCORE] End of Votes

[Jan N. <jan...@gm...>]

2008/12/11 Donal K. Fellows <don...@ma...>:
> Jan Nijtmans wrote:
>>
>> How strict is the deadline supplying TIP's?
>
> Strict, unless there's a very good reason otherwise. (If we're not strict,
> we'll never do a release...)

Fully agreed!

Jeffrey Hobb wrote:
> Something will need to be done
> about this, and it will be done in ActiveTcl if not the core.

I think ActiveTcl has the right to do that, but it would be a loss
if the ActiveTcl package names would be different from the
'official' ones. The question I actually meant to ask is:
Is this reason good enough for such a mini-tip. And then
I'm only talking about "Tcl", "Tk" and "TclOO", or maybe
just "TclOO" only. (I can implement this in a day, if needed,
so we don't need to delay anything, but it depends on how
much support there is from other TCT members)

Regards,
        Jan Nijtmans

Re: [TCLCORE] End of Votes

[Hemang L. <hl...@ci...>]

Jan Nijtmans wrote:
> 2008/12/11 Jeff Hobbs <je...@ac...>:
>   
>> And I'm annoyed again after finding another uselessly cased package.
>> What moron named a package TclOO?  Ugh?!  Something will need to be done
>> about this, and it will be done in ActiveTcl if not the core.
>>     
>
> Something can be done about it: I think it would be good that the TCT
> starts recommending all lower-case package names. That means that
> TclOO should become tcloo (or maybe simply just "oo"), Tcl
> should become tcl and Tk should become tk. Providing
> compatibility is easy. (For TclOO it is not really an issue,
> but because it is available as a separate package
> as well, I would do it anyway.)
>
> How about a mini-TIP, which simply proposes to recommend (but not
> require) all-lowercase package names. Then the core should do the
> same, just do "package provide"  twice, once with the original name,
> once with the all-lowercase name. It's zero risk, and still allows
> us to come with a better solution in Tcl 8.7.
>   
It's not as simple as doing "package provide" twice when tcl modules are 
involved. This is how our developers initially started out to support 
multiple cases for our packages. They had multiple "package provide" 
statements in their library to support FooBar, foobar and fooBar. 
However, when we started creating tcl modules for these packages, the 
"package provide" trick would no longer work.

An alternate approach I can think of to resolve this issue is to shift 
the burden to developers. Let the developer of a package decide whether 
their package should be registered as case-insensitive or not. For 
example, introduce a new subcmd say nocase:

package nocase FooBar 1.1

Any package registered with nocase subcmd can be loaded by the end user 
with any case. There would be no need for the end user to specify 
-strict option. Packages like Tcl, TclOO, BWidget, etc can immediately 
start including these cmds wherease tcltest and Tcltest can continue to 
remain case-sensitive. If there are conflicts with package names from 
two sources, it would be upto the respective developers to sort out or 
change the name or not use -nocase option.

If a tcl module is created for a package, make it a requirement for the 
developer to register the package as nocase, so that it can avoid 
potential conflicts with other packages in future. The [package nocase] 
command can be wrapped in catch to ensure that these pkgs can be used in 
older tcl versions as well.

Hemang.

Re: [TCLCORE] End of Votes

[Jan N. <nij...@us...>]

2008/12/11 Hemang Lavana <hl...@ci...>:
> It's not as simple as doing "package provide" twice when tcl modules are
> involved. This is how our developers initially started out to support
> multiple cases for our packages. They had multiple "package provide"
> statements in their library to support FooBar, foobar and fooBar. However,
> when we started creating tcl modules for these packages, the "package
> provide" trick would no longer work.

Here we are talking about packages implemented in C, not Tcl
modules, which has a lot of additional handling. Anyway, I'm very
interested to hear what the problem was, but I am confident
that for the situation we are talking about here, it doesn't apply.

Remember, the deadline for Tcl 8.6 TIP's actually already
passed, so anything doing now must be as simple as
possible with zero risk. To me, doing this for TclOO, Tcl
and Tk would be acceptable, but anything more than
that is not worth the risk.

Anyway, thanks for your remarks. Your proposal might
be a good solution, but it's too late for Tcl 8.6.

Regards,
           Jan Nijtmans

Re: [TCLCORE] End of Votes

[Hemang L. <hl...@ci...>]

Jan Nijtmans wrote:
> 2008/12/11 Hemang Lavana <hl...@ci...>:
>   
>> It's not as simple as doing "package provide" twice when tcl modules are
>> involved. This is how our developers initially started out to support
>> multiple cases for our packages. They had multiple "package provide"
>> statements in their library to support FooBar, foobar and fooBar. However,
>> when we started creating tcl modules for these packages, the "package
>> provide" trick would no longer work.
>>     
>
> Here we are talking about packages implemented in C, not Tcl
> modules, which has a lot of additional handling. Anyway, I'm very
> interested to hear what the problem was, but I am confident
> that for the situation we are talking about here, it doesn't apply.
>   
I was talking in the context of original TIP. Let me elaborate on our 
problem. We have a package FooBar and we would like to support 3 styles 
of package names: FooBar (original name), fooBar (camelcase) and foobar 
(lowercase). Our pkgIndex.tcl file for this pkg was written as follows:

# Begin pkgIndex.tcl
set pkg_version 1.1
foreach pkg_name {FooBar fooBar foobar} {
    package ifneeded $pkg_name $pkg_version "
           source foobar-file1.tcl
           source foobar-file2.tcl
           #...
           package provide $pkg_name $pkg_version
    "
}
# End pkgIndex.tcl

Some developers have also used the following style instead:

package ifneeded foobar $pkg_version "
      package require FooBar $pkg_version ;# bug here, need to specify 
-exact option
      package provide foobar $pkg_version
"

The pkgIndex.tcl file and the foobar-*.tcl files were distributed to the 
users and they could load the pkg with one of the 3 pkg names. We 
started using tcl modules since it makes it easier to deploy -- only 
single file is required to be given to the user. However, for such 
packages, we have to create 3 tcl modules files: FooBar-1.1.tm, 
fooBar-1.1.tm and foobar-1.1.tm and ask the users to install all the 3 
TM files. Having multiple "package provide" stmts in a single TM file 
doesn't work:

rtp-lds-016:73> pwd
/auto/wshlavana/ats5.0-main/lib/tcl8/8.4
rtp-lds-016:74> ls
FooBar-1.1.tm
rtp-lds-016:75> tclsh
% package require foobar
can't find package foobar
% package require FooBar
1.1
% exit
rtp-lds-016:76> cat FooBar-1.1.tm
package require Tcl
namespace eval foobar {}
proc ::foobar::print {args} {
    puts "FooBar 1.1: $args"
}
package provide FooBar 1.1
package provide foobar 1.1
rtp-lds-016:77>

If package names are made case-insensitive, then it resolves all these 
issues. Given that the original TIP did not pass due to backward 
compatibility concerns, I am proposing an alternate solution to let the 
developers decide whether their package name should be case-sensitive or 
not.

> Anyway, thanks for your remarks. Your proposal might
> be a good solution, but it's too late for Tcl 8.6.
>   
It may be late for 8.6 but if we agree upon one approach, then there can 
be feature parity between core tcl and ActiveTcl versions.

Thanks,
Hemang.