Consistency, Templates, Constructors, and D3

F i L witte2008 at gmail.com
Wed Aug 29 07:23:18 PDT 2012


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) { ... }
     }



More information about the Digitalmars-d mailing list