Re: [tcljava-dev] How to submit a code change (was: Patch for bug 121678)

[Mo D. <md...@cy...>]

On Wed, 8 Nov 2000, Christian Krone wrote:

> I you can give more than one distinct names for a channel,
> the methods in the subclasses of Channel have no idea which
> name they should print in the exception. This way you would
> have the following:
>   % read stdout
>   channel "file1" wasn't opened for reading

I don't get it, this already seems to work in Jacl.

tclsh8.4 % read stdout
channel "stdout" wasn't opened for reading

jacl from CVS % read stdout
channel "stdout" wasn't opened for reading

> Since I thought that an additional parameter "chanName" in
> the methods Channel.read() and Channel.write() class isn't
> a good idea, I did the same as Tcl does in tclIOCmd.c:
> Let the command implementations check the channel before they
> call the underlying channel operation, since they have the
> original channel name available.

Does this only apply if you use channel name like "file1"?

> > Surely these conditions have test cases in the
> > Tcl suite? If not, we really should
> > add them to Tcl first. That way
> > we can be sure Jacl and Tcl will
> > not diverge in the future.
> 
> I just did a grep through the Tcl test suite and there is no
> test which checks the name of a channel (as no good programmer
> should rely on this).

I was just looking around in ioCmd.test and it seems
like the conditions you mention are checked there.
Perhaps we need to move the ioCmd.test over into
Jacl.

> I still don't understand this point. Especially as the patch
> *removed* the overloaded StdChannel.getChanName() method.

My point was, I would like to get some regression test
for this stuff into Jacl. It seems like ioCmd.test
is what we want. It currently fails a bunch of
tests because fconfigure and -translation are
not implemented yet. How does that sound?

Mo