www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Clumsy class instantiation quibble

reply "Harvey" <hstroud ntlworld.com> writes:
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?
May 18 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
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?
May 18 2004
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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/
May 18 2004
parent reply "Harvey" <hstroud ntlworld.com> writes:
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/
May 18 2004
parent reply Derek Parnell <derek psych.ward> writes:
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
May 18 2004
next sibling parent reply Juan C <Juan_member pathlink.com> writes:
<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(...) ;
May 18 2004
parent reply "Harvey" <hstroud ntlworld.com> writes:
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(...) ;
May 19 2004
parent reply "C. Sauls" <ibisbasenji yahoo.com> writes:
------------------------------
class Foo
{
public:
   static Foo opCall()
   {
     return new Foo();
   }

   this()
   {
     // ...
   }
}

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

There you go.

-C. Sauls
-Invironz
May 19 2004
parent reply "Harvey" <hstroud ntlworld.com> writes:
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
May 19 2004
parent reply "C. Sauls" <ibisbasenji yahoo.com> writes:
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!
May 20 2004
parent reply "Harvey" <hstroud ntlworld.com> writes:
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!
May 22 2004
parent Kevin Bealer <Kevin_member pathlink.com> writes:
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
May 24 2004
prev sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
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/
May 19 2004