Side-effect free containers for E

[Tyler Close]

Marcs wrote responding to me (Tyler):
> Also, remember that one of the goals of E is to lure people
> in from outside
> our current community. One point in favor of flex
> containers is that people
> coming from outside the security world will expect to see
> such things, and
> would be surprised by their absence.

I think that such surprise would be a good thing. Flex containers
would be missing for a very good reason. Understanding this reason is
not very difficult. The short Person class example is quickly
assimilated. It also does an excellent job of pointing out 'least
authority' thinking to new users.

The other thing to keep in mind is that new users are going to run up
against E's lexical scoping style long before they hit this issue. If
they make it over that hill, then this little bump will be easy.

> Once people are inside
> our community,
> of course, they will realize quickly, with their increasing
> enlightenment,
> what they should do (and what features of E they should
> avoid) when they are
> building real secure systems :-)

I don't think building a minefield is an admirable goal. If we want to
be able to throw thousands of newbie programmers at E, then there
should be as few pitfalls as possible.

> I have not yet built a program in E in which the existence of flex
> containers threatened my security architecture: I have used
> flex containers
> when they made sense and did not violate my security
> requirements, and not
> used them when they did violate my security.

That you are capable of quickly and easily making that distinction
makes your point irrelevant. We are talking about what non-security
minded coders will do.

> As long as E
> supports styles of
> programming that enable security for applications that need
> it, I believe it
> is okay for E to support styles of programming that don't
> prohibit insecure
> styles for applications that don't.

I think Javasoft would say the same about Java. Why are we making E?

>From my perspective, the whole point of E is to facilitate, and
encourage, writing secure code.

> Bottom line, unless the transition for an ordinary programmer from
> flex/const containers to Hydro containers is as easy as
> falling off a log
> (and I don't know the Hydro containers so I don't know,
> would the transition
> be that easy?), I would have to oppose this change.

I posted a link, http://www.waterken.com/Hydro/2.0/. Download and try.

The main difference that we're talking about is that instead of:

	container add(new_element);

you have to write:

	container := container with(new_element);

All of the read-only operations are pretty similar.

Could you do that while falling off a log?

The Hydro containers also offer a bunch of other useful features that
the E containers don't (multimap and multiset, sorted containers,
splitting containers, constant-time reverse, ...).

Tyler


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com