Why self?

[Alex Martelli]

Tim Hammerquist wrote:
        ...[snipped lots of intense agreements]...
> Trusting a language structure to protect against malicious or simply
> incompetent users is bad design, and is likely to inhibit flexibility.

Not too sure I agree fully with THIS point.  The language structure PLUS
a controlled runtime environment, a la JVM (as opposed to just Java as a
language but with native code generation), COULD be a decent design to
offer some level of protection against deliberate attacks.  OK, the JVM
doesn't have a great track record for its first few years, admittedly,
but that's a question of careful execution as well as of whether the
overall design is "bad".  Oberon, I think, has a similar language+OS
security strategy.

Note that I _am_ talking strictly about protection against deliberate
attacks.  "Against stupidity, the Gods themselves fight in vain"!-)

Inhibiting flexibility is a given for ANY security mechanism, alas.

Python's own security architecture, based on the idea that untrusted
code is a small percentage of all code you write and run and thus is
best dealt with explicitly and separately from the vast mass of trusted
code, is of course also quite a viable alternative design.  I'm told
its own track record, so far, isn't all that outstanding either -- again,
particularly with security, "the devil is in the details"... I don't
think, therefore, that you can judge the worth of a security _architecture_
from the dubious track record of an _implementation_ of that architecture;
defects of detailed execution can obscure the architecture's worth.


> To the truly intent or truly clueless, strict typechecking (a la C/Java)
> protects against misuse about as much as Python's __instancevar munge
> technique.

"Strict typechecking" in C or Java is done badly anyway (look at Haskell
for some indications of how compile-time type handling SHOULD be, if you
want it!), and at least in C it has absolutely no intention to protect
against any deliberate attack (the story's different in Java, with a JVM
underneath, but, see above).

Regarding _accidental_ misuse, i.e., errors, having the compiler do more
checks does help a bit -- if nothing else, you learn about such errors
a few seconds earlier, and that must be worth SOMEthing (as long as it
doesn't lull you into a false belief that therefore you don't need code
inspections and unittests -- of course you do, no compiler will catch
a typo such as + where you meant -, and that can be a disaster!-).

The problem is whether the costs (in development productivity) of such
compile time checking are worth the gain (in getting a bit better error
diagnostics a tad earlier, in making the compiler's life easier in
generating good, fast code).  I think that, in most situations, they
don't.  But it's a tradedoff to evaluate, not a black-and-white issue.

The complication of private/protected/friendly/etc on the other hand
IS an unrelieved mess.  Python's '__' hack isn't much better.  I do not
think we have yet seen a perfectly clean and totally usable way to
express the desired separation of interface from implementation, one
that makes it totally clear to the author and reader of each piece of
code whether it's interface, or implementation, of each given object
and class, that said code is dealing with.  Not in OO programming, at
least, where you need to deal with (e.g.) subclassing too.  For pure
modular programming, Limbo (a Bell language with which they build
their latest 'Inferno' OS), for example, shows an excellent way (and
it's definitely not the only one).  But we DO want OO for its many
benefits over simple modular programming -- and how to best separate
interfaces and implementation in THAT context is not obvious.


Alex