There is a better way... use the provided and language-consistant 'new' operator.  The same which is used to explicitly allocate structures, arrays, etc.

Maybe I just don't understand the issue...  I could maybe understand a desire to get rid of new for auto-objects, but then again I've even had a case where I re-used an auto variable.  (Probably a no-no but it works for now.)

Then again, using the static opCall trick is convention-consistant, because its the same way we have to approximate constructors for structures.

-C. Sauls
-Invironz

Harvey wrote:
> Hmm, that's hardly convenient though; so for every class where I wanted this
> facility I'd have to provide a static opCall() ? There has to be a better
> way!

Seems like we've just turned full circle, as part of my suggested improvement to class instantiation involves the removal of the new operator. Using 'new' does make it explicit that an object is (somehow, somewhere) being allocated, but does this need spelling out? By definition, when a constructor gets called this will be the case anyhow, so why add clutter to our programs?  In C++ there's an important distinction to be made between stack allocated objects and those allocated on the heap, or to be more accurate, the method of accessing an object; as this is all made transparent in D (unless raw pointers are employed) then this becomes far less relevant.

But to repeat myself, my main problem is with the tautological syntax 'MyClass c = new MyClass();'.  It's nice that features such as 'super' and 'this' (when used for defining constructors, as opposed to naming them the same as the class a la C++) avoid the tedious, less maintainable class name repetition, so why spoil it by this way of instantiation?

I'm not sure if I could use a nonstatic opCall to *almost* do what I'm after:

MyClass c; c(1,2,3);

Probably not as the 'this' getting passed into the opCall would be invalid, but even so, it would fall short anyhow.

It's obvious the D community's divided over this one, so perhaps I'll leave it there!

Cheers.



"C. Sauls" <ibisbasenji@yahoo.com> wrote in message news:c8hoap$2cvv$1@digitaldaemon.com...
> There is a better way... use the provided and language-consistant 'new' operator.  The same which is used to explicitly allocate structures, arrays, etc.
>
> Maybe I just don't understand the issue...  I could maybe understand a desire to get rid of new for auto-objects, but then again I've even had a case where I re-used an auto variable.  (Probably a no-no but it works for now.)
>
> Then again, using the static opCall trick is convention-consistant, because its the same way we have to approximate constructors for
structures.
>
> -C. Sauls
> -Invironz
>
> Harvey wrote:
> > Hmm, that's hardly convenient though; so for every class where I wanted
this
> > facility I'd have to provide a static opCall() ? There has to be a
better
> > way!

>But to repeat myself, my main problem is with the tautological syntax 'MyClass c = new MyClass();'.  It's nice that features such as 'super' and 'this' (when used for defining constructors, as opposed to naming them the same as the class a la C++) avoid the tedious, less maintainable class name repetition, so why spoil it by this way of instantiation?

Not to reawaken this argument, but the rationale for the current syntax is that with references, the type of the reference is only related to the type of the object.  There are plenty of times when you want "A obj = new B;", either because you are going to modify obj to point to a non-B later, or you want to limit the following code to the functionality of the A interface.

Another case where this happens:

TypeA x = new TypeB;

if (some_option) {
// Decorator pattern
x = TypeC(x);
}

In fact, this is a good idea in a template definition: if a type needs to be convertable (later-on) to a T pointer, use a T pointer to store it in the constructor.  Then if it won't convert, it becomes null.  This is good because the error is "promoted up" from a rare case, to every-run, which is a little like promoting runtime bugs to compile time.

Kevin