Preventing execution of a method

[rdmurray at bitdance.com]

On Thu, 11 Dec 2008 at 13:41, Emanuele D'Arrigo wrote:
> On Dec 11, 7:48 pm, Bruno Desthuilliers
> <bdesth.quelquech... at 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