On Wednesday, 1 October 2014 at 18:37:50 UTC, Sean Kelly wrote:
On Wednesday, 1 October 2014 at 17:53:43 UTC, H. S. Teoh via
Digitalmars-d wrote:
But Sean's idea only takes strings into account. Strings
aren't the only
allocated resource Phobos needs to deal with. So extrapolating
from that
idea, each memory management struct (or whatever other
aggregate we end
up using), say call it MMP, will have to define MMP.string,
MMP.jsonNode
(since parseJSON() need to allocate not only strings but JSON
nodes),
MMP.redBlackTreeNode, MMP.listNode, MMP.userDefinedNode, ...
Nope, still don't see how this could work. Please clarify,
kthx.
Assuming you're willing to take the memoryModel type as a
template argument, I imagine we could do something where the
user
can specialize the memoryModel for their own types, a bit like
how information is derived for iterators in C++. The problem is
that this still means passing the memoryModel in as a template
argument. What I'd really want is for it to be a global, except
that templated virtuals is logically impossible. I guess
something could maybe be sorted out via a factory design, but
that's not terribly D-like. I'm at a loss for how to make this
memoryModel thing work the way I'd actually want it to if I were
to use it.
If you were to forget D restrictions for a moment, and consider
an idealized language, how would you express this? Maybe
providing that will trigger some ideas from people beyond what we
have seen so far by removing implied restrictions.
