Am I right in thinking that it isn't legal to do the following in D to create an object and bind it to a reference variable:

TestClass    tc(/* args */);

instead we're forced to use:

TestClass    tc = new TestClass(/* args */);

Why has the first way been disallowed? I know Java also uses the latter's syntax but it's clumsy, necessitating the repetition of the class name.

The only slight anomaly the above has would be having to use TestClass tc(); to mean a reference to an automatically instantiated class object and TestClass tc; to mean an unbound reference, which would be null assigned. Of course the existing way should be kept, but I'd much prefer the shortened form to also be available, as coders will often want to both create a class reference and instantiate an object of this same class.

What say the D community?

We've said often that this should be the case for auto classes, with the addition (to your example) of the auto keyword, as in

    auto TestClass    tc(/* args */);



"Harvey" <hstroud@ntlworld.com> wrote in message news:c8d5vo$uog$1@digitaldaemon.com...
> Am I right in thinking that it isn't legal to do the following in D to create an object and bind it to a reference variable:
>
> TestClass    tc(/* args */);
>
> instead we're forced to use:
>
> TestClass    tc = new TestClass(/* args */);
>
> Why has the first way been disallowed? I know Java also uses the latter's syntax but it's clumsy, necessitating the repetition of the class name.
>
> The only slight anomaly the above has would be having to use TestClass tc(); to mean a reference to an automatically instantiated class object and TestClass tc; to mean an unbound reference, which would be null assigned. Of course the existing way should be kept, but I'd much prefer the shortened form to also be available, as coders will often want to both create a class reference and instantiate an object of this same class.
>
> What say the D community?
>
>

Harvey wrote:

>Am I right in thinking that it isn't legal to do the following in D to
>create an object and bind it to a reference variable:
>
>TestClass    tc(/* args */);
>
>instead we're forced to use:
>
>TestClass    tc = new TestClass(/* args */);
>
>Why has the first way been disallowed? I know Java also uses the latter's
>syntax but it's clumsy, necessitating the repetition of the class name.
>
>The only slight anomaly the above has would be having to use TestClass tc();
>to mean a reference to an automatically instantiated class object and
>TestClass tc; to mean an unbound reference, which would be null assigned. Of
>course the existing way should be kept, but I'd much prefer the shortened
>form to also be available, as coders will often want to both create a class
>reference and instantiate an object of this same class.
>
>What say the D community?
>  
>
Me too as it will make code more maintainable.

-- 
-Anderson: http://badmama.com.au/~anderson/

It's more an aesthetic consideration but it seems a lot of extra typing for such a frequently done thing, and the use of the 'new' operator seems superfluous. For example:

SomeClass    sc;
...
sc = new SomeClass();

Why the 'new' keyword, or would its absense cause an ambiguity?

Don't get me wrong, what (little) I've seen and used of the language to date looks really promising, but I guess there's always room for improvements and wart removal, and you can't please all the people all of the time ;-)


> >
> >What say the D community?
> >
> >
> Me too as it will make code more maintainable.
>
> -- 
> -Anderson: http://badmama.com.au/~anderson/

On Tue, 18 May 2004 21:18:30 +0100, Harvey wrote:

> It's more an aesthetic consideration but it seems a lot of extra typing for such a frequently done thing, and the use of the 'new' operator seems superfluous. For example:
> 
> SomeClass    sc;
> ...
> sc = new SomeClass();
> 
> Why the 'new' keyword, or would its absense cause an ambiguity?
> 
> Don't get me wrong, what (little) I've seen and used of the language to date looks really promising, but I guess there's always room for improvements and wart removal, and you can't please all the people all of the time ;-)
> 
>>>
>>>What say the D community?
>>>
>>>
>> Me too as it will make code more maintainable.
>>
>> -- 
>> -Anderson: http://badmama.com.au/~anderson/

Well it could be that sometimes we don't actually want the object to be instantiated at the point of its declaration.

 SomeClass    sc;
 ...
 if (conditionX)
  sc = new SomeClass();
 else
  sc = new SomeClass(Y);

Also, what would happen if the class didn't provide a  'this()' method, that is a ctor without arguments.

-- 
Derek
19/May/04 10:22:28 AM

<snip>
> SomeClass    sc;
> ...
> if (conditionX)
>  sc = new SomeClass();
> else
>  sc = new SomeClass(Y);
</snip>

Indeed, or how about:

Base b ;

if (conditionX)
b = new derivedX(...) ;
else
b = new derivedY(...) ;

That'd be fine, what I've said wouldn't preclude this.  I wasn't proposing getting rid of reference assignments on separate lines to their declaration, so you're code would simply read:

SomeClass    sc;    // Null assigned 'unbound' ref
...
 if (conditionX)
    sc = SomeClass();    // Calls SomeClass.this()
 else
    sc = SomeClass(Y);    // Calls SomeClass.this(Y)

Likewise the other code fragment becomes:

Base b ;

 if (conditionX)
  b = derivedX(...) ;
else
  b = derivedY(...) ;

"Well it could be that sometimes we don't actually want the object to be instantiated at the point of its declaration."

As can be seen below, this would remain optional:

SomeClass    sc;       // Null assigned 'unbound' ref
SomeClass    sc();    // Ref var assigned to heap allocated class object

I think that would cover all bases? It's not a ground breaking proposal I'm suggesting, just more a streamlining of syntax.

Cheers.

(btw: if anyone's interested then another person has started a thread 'three improvements for constructor syntax' in which he puts the same argument a little more eloquently then I do :-)


"Juan C" <Juan_member@pathlink.com> wrote in message news:c8ebsf$2upt$1@digitaldaemon.com...
> <snip>
> > SomeClass    sc;
> > ...
> > if (conditionX)
> >  sc = new SomeClass();
> > else
> >  sc = new SomeClass(Y);
> </snip>
>
> Indeed, or how about:
>
> Base b ;
>
> if (conditionX)
> b = new derivedX(...) ;
> else
> b = new derivedY(...) ;
>
>

Derek Parnell wrote:

>On Tue, 18 May 2004 21:18:30 +0100, Harvey wrote:
>
>  
>
>>It's more an aesthetic consideration but it seems a lot of extra typing for
>>such a frequently done thing, and the use of the 'new' operator seems
>>superfluous. For example:
>>
>>SomeClass    sc;
>>...
>>sc = new SomeClass();
>>
>>Why the 'new' keyword, or would its absense cause an ambiguity?
>>
>>Don't get me wrong, what (little) I've seen and used of the language to date
>>looks really promising, but I guess there's always room for improvements and
>>wart removal, and you can't please all the people all of the time ;-)
>>
>>    
>>
>>>>What say the D community?
>>>>
>>>>
>>>>        
>>>>
>>>Me too as it will make code more maintainable.
>>>
>>>-- 
>>>-Anderson: http://badmama.com.au/~anderson/
>>>      
>>>
>
>Well it could be that sometimes we don't actually want the object to be
>instantiated at the point of its declaration.
>
> SomeClass    sc;
> ...
> if (conditionX)
>  sc = new SomeClass();
> else
>  sc = new SomeClass(Y);
>
>Also, what would happen if the class didn't provide a  'this()' method,
>that is a ctor without arguments.
>
>  
>
The original version would still work.  VB does basicly what is proposed (different syntax of course).  You can write (in VB) both:

dim obj as Object
obj = new Object

or

dim obj as new Object

-- 
-Anderson: http://badmama.com.au/~anderson/

------------------------------
class Foo
{
public:
  static Foo opCall()
  {
    return new Foo();
  }

  this()
  {
    // ...
  }
}

Foo f = Foo();
------------------------------

There you go.

-C. Sauls
-Invironz

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!

"C. Sauls" <ibisbasenji@yahoo.com> wrote in message news:c8g78m$2m9e$1@digitaldaemon.com...
> ------------------------------
> class Foo
> {
> public:
>    static Foo opCall()
>    {
>      return new Foo();
>    }
>
>    this()
>    {
>      // ...
>    }
> }
>
> Foo f = Foo();
> ------------------------------
>
> There you go.
>
> -C. Sauls
> -Invironz