Some issues with chan type

[Qtvali]

At first, I didn't see in chan specification, how to handle the case
when there is chan array used with select switch. In my imagination,
just making so that <-chanarray will do select over that array would
be enough.

Also, would it be too big overload to language, if it was possible to
simply add additional receivers, possibly non-typed, to channels? I
mean such possibility:
channel chan int;
listener chan = makeListener(channel, 20);
Such that listener being full would block the channel and in array of
listeners I would use simultaneous select and type swithch for an
array of listeners. This would allow easier debugger writer so that I
don't need to add wrapper to all my channels being debbuged - I would
just add listener when some assert condition fails for process using
that channel, for example, or easily debug some set of given channels
without wrapping them to wrapper of specific kind.

The case, when this would be needed, is when I want to log what's
going on in several channels.

[Russ Cox]

[It would help a lot if you edited your posts more,
both to make them shorter and to make them
clearer. Editing takes time, but you're writing
to over 2,000 people. Many of your posts are
so long that I doubt many of those people read them.
This one is shorter than most but could still use editing:
I can't tell exactly what you're asking.]

Since you mentioned array select, I will say
that we intentionally left array select out.
It's an expensive operation and can often be
avoided by arranging for the various senders
to send on a shared channel instead.

Russ

[Qtvali]

On Dec 13, 3:15 am, Russ Cox <r...@golang.org> wrote:
> [It would help a lot if you edited your posts more,
> both to make them shorter and to make them
> clearer.  Editing takes time, but you're writing
> to over 2,000 people.  Many of your posts are
> so long that I doubt many of those people read them.
> This one is shorter than most but could still use editing:
> I can't tell exactly what you're asking.]

[I am getting more filtered all the time. How many are getting each
message as an e-mail and reading without gmail? I suggest people to
not use old generation of nonthreaded mail readers anyway ...I don't
know the exact issues of my wording, as I'm having foreign language as
native language, I would like to have specific questions and
corrections to fix both my english use and writing style; some
sentences might appear as word-to-word translations from estionian or
using some odd simplified or plain wrong structure of english sentence
I have pattern-matched out of some kinds of english books or texts and
generated a wrong kind of primitive from that pattern; I might have
some errorous set of such primitives in constant use and fixing some
of them might make my use of english lot more productive]

[Tambet]

> Since you mentioned array select, I will say
> that we intentionally left array select out.
> It's an expensive operation and can often be
> avoided by arranging for the various senders
> to send on a shared channel instead.

Is this shared channel also an expensive operation?

> Russ

--
Tambet

[Russ Cox]

> Is this shared channel also an expensive operation?

Not any more expensive than any other channel.
And there's only one, which makes the select
much easier.

Russ

[Qtvali]

Ok.

By additional receivers I meant the possibility to split a channel,
making it inherently able to have several receivers.
This could be:
anotherchannel := channel.split();

It would be usable to debug channels without putting them all into
wrappers. Like that:
channeldebugger.register(channel);
Where channeldebugger is left out from release and might look like
that:
for a := <-chan {
// Write a to log