TempAlloc Overhaul

[Jose Armando Garcia]

On Sat, Jun 11, 2011 at 4:12 PM, Robert Jacques <sandford at jhu.edu> wrote:
> On Sat, 11 Jun 2011 12:35:43 -0400, Jose Armando Garcia <jsancio at gmail.com>
> wrote:
>
>> On Sat, Jun 11, 2011 at 1:26 PM, dsimcha <dsimcha at yahoo.com> wrote:
>>>
>>> I've overhauled my TempAlloc proposal based on some of the suggestions
>>> I've
>>> received.  Here are the major changes:
>>>
>>> 1.  I've reconsidered and decided TempAlloc belongs in its own Phobos
>>> module
>>> (std.tempalloc) instead of in core.memory, mainly because it uses Phobos
>>> in
>>> ways that aren't easy to get rid of.
>>>
>>> 2.  Move uninitializedArray (formerly newVoid) to its own pull request
>>> for
>>> inclusion in std.array.  This keeps the TempAlloc proposal more tightly
>>> focused.
>>>
>>> 3.  Make alignedMalloc and friends private for now, again to make the
>>> proposal more tightly focused.
>>>
>>> 4.  Rename tempdup to tempArray to emphasize that is semantics are more
>>> similar to std.array.array than .dup w.r.t. narrow strings.
>>>
>>> 5.  Move newStack into the TempAlloc namespace and rename it
>>> TempAlloc.newArray.
>>>
>>> 6.  TempAlloc.newArray now handles multidimensional arrays.  Its syntax
>>> is
>>> slightly modified to accommodate this.  Before:
>>>
>>> double[] foo = newStack!double(100);
>>>
>>> After:
>>>
>>> double[] foo = TempAlloc.newArray!(double[])(100);
>>>
>>> Code:
>>>
>>> https://github.com/dsimcha/TempAlloc
>>>
>>> Docs (NOT the same as the old URL):
>>>
>>> http://cis.jhu.edu/~dsimcha/d/phobos/std_tempalloc.html
>>>
>>
>> Just a high-level comment.
>>
>> Now that you moved it to its own namespace do you have a need for a
>> struct with only static method? I think it is an abuse of the language
>> to use struct as a way of namespacing.
>
> First, TempAlloc was originally developed in its own namespace. Second,
> there are no name conflicts between core.memory and TempAlloc which would
> require a sub-namespace. Third, Structs don't provide a true namespace. What
> you're neglecting is that each of those function names can't stand by
> itself. For example, people assume malloc and free always refer to the C
> functions. So, the TempAlloc functions would normally be TempAllocMalloc or
> TempAllocFree. But once the number of functions like this grows past a
> certain size, using TempAlloc.free, becomes syntactically nicer than
> TempAllocFree.
>

Not exactly sure what your argument for using a struct is. The
argument that the function names collide with existing functions and
the assumption about user semantic of such names says something about
the name of the function and not the use of a struct as namespacing
construct. Having said that we don't have to call them malloc and
free. It is a stack so maybe pushMemory() and popMemory() is better.

Again, looking at the implementation I don't see a need for struct.
True OO languages use classes/struct with only static methods when
they want to expose an non-OO API. In those cases you can argue their
decision on the fact that the language has limitation expressing
non-OO concepts. D doesn't have such limitations.

You can clearly implement this using a OOD so using struct and class
is okay. But the API that is expose is not OO so I don't see the need
for it. D provides so many features to get around this naming problem.
Use them. Don't overload the struct concept.