Re: Capabilities interact nicely with Substructural Types and Reactivity

On Thu, Sep 12, 2013, at 07:34 PM, David Barbour wrote:
> DeepFrozen and Immutable are practical ways to solve real problems.
> 
> But they are achieved by reflection and type systems, outside OOP and
> object capabilities.
> 
> Therefore, it is unreasonable to point at objects or capabilities as
> providing the answer.

Thanks for the explanation.  I am indeed interested in
practical ways to solve real problems.  From my perspective,
I don't care whether the credit for the solution is given to
objects, capabilities, or to types; if the solution achieves
the goals, I'm good with it.  Therefore, the current situation
doesn't sound problematic to me.  I realize others may feel
differently.

> Further, DeepFrozen and Immutable do not have the same fine-grained
> security-by-composition benefits as object capability model; they do not
> enable the deep interleaving of trusted and untrusted code. They are very
> blunt force tools.

I'm not sure I understand exactly how DeepFrozen or
Immutable prevent the deep interleaving of trusted and
untrusted code: there's not necessarily a one-to-one mapping
between "pure" and "untrusted".  But, more importantly,
I'm not sure whether it is valuable or desirable to interleave
them at too fine a granularity.  Do you have an example
or use case where this is a serious problem?  Or, an argument
why the current approach is not good enough for building
secure systems?  In the object capability world, we have
a rule of thumb: make trust distinctions explicit in the
class hierachy.  This rule of thumb suggests to me that
it might not be a good idea to routinely interleave trusted
and untrusted code very closely together (for instance,
together in the same method), though I'm sure there are
going to be exceptions and valid uses.

I'm afraid the discussion on state lost me (do you have
an example?), so I'll leave that to others who understand
this area better than I do.

-- David