Side-effect free containers for E

[Tyler Close]

Markm wrote:
> Frankly, you may be right.  But it would be interesting
> seeing you make this
> argument to object programmers without invoking security
> issues.  That's as
> in "security per se", as distinct from normal software engineering
> modularity issues.  From now on, I'll refer to the
> object-without-security-per-se perspective as simply the
> object perspective.
>
> For concreteness, let's contrast two protocols for a
> Mutable Cell (ie, Slot
> or Location).  Using Java interface declarations as an
> interface description
> language (for which they are not bad):
>
> Protocol M (for MarkM):
>
>      public interface CellReader {
>          Object getValue();
>      }
>
>      public interface CellEditor extends CellReader {
>          CellReader readOnly();
>          void setValue(Object newValue);
>      }

Designer M is schizophrenic.

The designer of protocol M was concerned with security, just unable to
implement it. If the designer had not been concerned with security,
then the protocol would have been:

	public
	interface Cell
	{
		Object get();
		void set(Object value);
	}

Protocol M is therefore neither a good object (without security)
design, nor a good capability design. It is some weird half-breed with
the advantages of neither.

Tyler


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com