Proposal: Pooled memory management
Sven_Panne at BetaResearch.de
Mon Jan 20 04:43:38 EST 2003
> * I want to get v1.0 of the spec fixed. We are really only
> in bug fix mode for quite a while and only the finalizer
> problems held us back from finishing the spec.
That's OK and I understand your motivation. Let's finish v1.0 first.
> * I am sure there are plenty more useful FFI-related
> libraries. However, the initial plan was to define basic
> functionality on top of which more elaborate schemes can
> be implemented. We need to draw the line somewhere. [...]
But I strongly disagree here: The initial plan was to make a very small,
but sufficient addition to the language (=> foreign import/export), which
can be implemented easily on existing systems. In this respect, we have
reached our goal quite elegantly IMHO.
The related libraries are a totally different beast: Minimality is *not*
a design goal here. Otherwise we might be happy with e.g.
alone. Or another example: Why should we include such trivialities like
in the FFI spec? Minimality? Possibility of a lightning-fast special
implementation? Definitely not. The basic task of a library (or a
collection of related libraries) is to establish a common "language" and
make common notions (like scoped or pooled allocations) explicit. Looking
at the OO world, that's the reason for all this pattern hype.
In a nutshell: Let's include as many useful "patterns" in the next FFI spec
versions as possible! Otherwise we might talk the same language without
More information about the FFI