Re: Capabilities interact nicely with Substructural Types and Reactivity

On Thu, Sep 12, 2013 at 4:38 PM, Karp, Alan H <[email protected]> wrote:
>
> Is making “new” not be ambient the only solution?  For example, would
> instantiating a new instance for every invocation achieve the same goal
> while allowing the object to invoke “new” during that invocation?
>
Creating a new instance per invocation can partially work. You still don't
have determinism if the output type is 'selfish' in E's terms. It is a very
inefficient and undesirable approach, especially if you do any sort of
staged programming - i.e. it is not unusual to have a one time 'set up'
cost for a functional pipeline to run a bunch of computations efficiently.
You would be asking to pay the one-time cost every time.

Making "new" not be ambient is simple, elegant, precise, a great fit for
the capability security model, and has many side-benefits that are often
ignored by panicking OO programmers - such as more explicit variations of
'new' enabling orthogonal persistence and great stability across runtime
code changes. And it doesn't really need to address all new objects, just
those with state or identity (selfish objects).

The main problem people have with this solution is... threading 'new'
through almost every method call.

I often think it might be worthwhile to find a balance between
ambient-authority syntax with capability-secure semantics, such as enabling
a powerbox object to be threaded implicitly but manipulated explicitly.
Combined with good visualization in the IDE, we could still ensure
desirable 'visibility' properties.

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk