Era Scarecrow wrote:
suggested new was the constructor & allocator, meaning you'd
have to have in depth detail of both steps in order to override
it later. Abstraction then is thrown away and the black box
method becomes a white/clear box method, encapsulation goes out
the window.
You raise a valid issue here. However, I think there's an easy
solution (similar to what foobar was suggesting) which separates
the allocator from the constructor but still allows for easy
defaults and consistent syntax at object instantiation.
Here's my idea:
class A
{
private void* myAlloc() {
return GC.alloc(A);
}
this new1() { ... } // automatic allocator
this new2() @alloc(myAlloc) { ... }
}
class B : A
{
override this new1() {
super.new1();
...
}
override this new2() {
// for 'new2' we could either:
// 1. Default to automatic.
// That's probably bad because you don't know
// when you're potentially overriding a
// specialized allocator in the super class.
// 2. Compiler error: Must define an allocator
// with @alloc(...) for this constructor
// because super.new2 override the automatic one.
}
// So we'd probably want to require:
private void* b_alloc() { ... }
override this new2 @alloc(b_alloc) { ... }
}
