Newbie switching from TCL

[Alex Martelli]

"Robin Becker" <robin at jessikat.fsnet.co.uk> wrote in message
news:0k4seKAxmAp5EwR8 at jessikat.fsnet.co.uk...
> In article <8o0scj01hch at news1.newsguy.com>, Alex Martelli
> <alex at magenta.com> writes
> ....
> etc etc etc etc; crappy === baroque === perl === win32 or is that too
> pre-modernist.

It's, to be extremely nice to you, over-simplified to the point of
ludicrousness.  You asserted that something couldn't be done
(on a system you clearly know little about: it's wiser to avoid
talking about systems one doesn't know well, _particularly_
rich and complex ones); now, faced with the fact that, yes, of
course it can be done (in several ways, at different levels:
kernel, low-level COM, simplified higher-level COM/Automation,
were three I showed), you seem to be retreating into
name-calling against this sytem you dislike so much.

I prefer simplicity; but I'd never be so foolish as to assert
that something "can't be done" in Perl (for example), despite
knowing it passably well, exactly because it's such a rich and
baroque environment.

In this specific case, there are reasonable justifications for
some of the architecture's complexities.  COM, the main level
of access to the system's functionalities, is not all-pervasive:
in particular, it does not extend all the way down to the kernel
and other very low-level subsystems, because those systems
predate the invention and spread of COM architecture.  Quite
similarly, no object-oriented or component-oriented approach
will ever be all-pervasive in Unix systems, because the syscalls
(which have been around for ages) will predate such a system.

You either scrap the whole thing and restart from scratch, or
take a vow against any architecture that wasn't around in '70,
or resign yourself to having at least two different approaches
to the same functionality.  The latter choice is no doubt the
most sensible one in practice.

COM itself tends to come in two layers: a lower one, optimized
for speed; a higher one, easier to use, with some sacrifice of
performance.  The latter is what you'd normally approach from
such environments as Python, or Basic, but sometimes it can
be quite handy that the lower-level is also exposed.  Do you
consider Python 'baroque' or 'crappy' when it takes a similar
two-pronged approach, e.g. the two (abstract and concrete)
layers of calls in the C API?

Of course, such two-pronged approaches are not always
very well designed; IDispatch itself, the core of most 'higher
level' COM architectures, has serious design flaws, for
example.  Still, I consider 'events' one of the cases which
were designed pretty well.


If I were to recommend one uniform 'eventing' approach in
Win32, in the abstract, it would be the higher-level COM one --
the performance loss is slight, the uniformity rewarding.
Only rarely, when really top performance or some peculiar
requisite demands, may one have to dip lower.  Unfortunately,
Python's win32com may not support this optimally; but that
is another issue.

What ever gave you the idea that support for 'select' is the
end-all, be-all of 'eventing', or even a good design for
general 'eventing' at all...?


Alex