class allocators should be more encapsulated

[Frits van Bommel]

Luís Marques wrote:
> Frits van Bommel wrote:
>> I don't think that's what custom allocators were designed to do. They 
>> should only allocate some memory (and register it with the gc if 
>> necessary).
> 
> Well, allocators do take parameters. The only reason for that has to be 
> being able to customize how the memory is allocated, right? From what I 
> can see in my example my example still applies (I have seen several 
> people use new for singleton patterns). Perhaps you disagree. Would you 
> care to elaborate?

Yes they do take parameters, and the reason is indeed to customize how 
memory is allocated. But unless they throw an exception, they do have to 
actually _allocate_ some memory. If they don't throw, the return value 
must be a void* to a newly-allocated piece of memory.
So what I gather you're trying to do (potentially return a pointer to an 
already-existing object) isn't acceptable behavior for a custom allocator.

>> Well, in D the factory method can be static opCall(), so allocation 
>> can look like this:
>>     ClassType("my string")
>> which looks a lot cleaner than the normal ClassType.create("my string").
> 
> Well point out, thanks!
> 
> But still, isn't new ClassType("my string") better?

A 'new' (that doesn't throw) is supposed to always actually creates a 
*new* object...
Anything that conditionally creates a new object to return should really 
be a function/method/static opCall, not a custom allocator or 
constructor. It's just not what they're meant to do.