On Thu, 11 Dec 2008 at 13:41, Emanuele D'Arrigo wrote:
On Dec 11, 7:48?pm, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.fr> wrote:
or to provide read-only
access. I.e. right now I'm working on the graphical client which
potentially could be rewritten entirely by the users. It is necessary
and perfectly reasonable for the client module to access some of the
objects to be represented graphically, but those objects shouldn't be
modifiable by it.
Why so ? At worst, they'll break everything.
-IF- the application was single-user yes, it wouldn't be a big deal.
But as it is potentially multi-user, I don't want one party to corrupt
the application for everybody else. Say I'm writing a multi-player
version of a card game (I'm not). For the sake of the argument let's
imagine that the players are all playing on the same computer, taking
turns. However, they are using a GUI written by one of the players who
unbeknown to them, has written it to modify the game state
appropriately and give himself the right cards at the right time. If
the game state is read-only and can only be queried but not modified
by the GUI, the player can rewrite the GUI but cannot cheat. Isn't
this a legitimate concern?
In that case, you've got much bigger problems than a lack of private
methods. As someone else pointed out, _no_ language is secure in the
face of this requirement.
Proving this kind of interface requires a lot of careful security oriented
thinking. Whole operating systems have been designed to address these
kinds of issues...
--RDM
--
http://mail.python.org/mailman/listinfo/python-list
