www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Static opCall and class instantiation

reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
I've been reading an old thread from 2004 called "Clumsy class 
instantiation quibble." This example here gives one solution to the 
"problem" (which is hardly a serious concern, really it's just syntactic 
sugar, but bear with me):

http://www.dsource.org/projects/tutorials/wiki/OpCallExample

I like this. It wraps the "new" keyword in a static opCall, allowing you 
to drop the new keyword whenever you construct a class instance.

(The example claims this is the "C++ syntax," but the semantics are 
quite different, as when you do this in C++ you are allocating it on the 
stack.)

Python does exactly this. Like D (and Java, for that matter), class 
instances can only be created by reference, meaning the new keyword is 
redundant, and so the language dropped it entirely. I never understood 
why Java bothered to keep it, and I still don't get it in D. It's still 
useful for structs, which can be put on the stack, yes? So I think D 
should support both syntaxes.

To sum up suggestions (posted by "Harvey" <hstroud ntlworld.com>) from 
the old thread:

SomeClass  sc1;      // null reference
SomeClass  sc2();    // reference assigned to GC-allocated instance
SomeClass  sc3 = SomeClass(); //  same as above
sc1 = SomeClass();   // sc1 assigned to GC-allocated instance
sc1 = new SomeClass(); // same as above

Because there is only one way to instantiate a class, all of these 
different syntaxes mean the same thing. The "new" keyword is not needed, 
but should still be kept. And if the various Python code I've read is 
any guide, dropping the "new" keyword is still eminently clear for the 
reader.

As far as I could tell, the original thread never really came to a 
conclusion. I was wondering what the D community thought of it now, 
almost exactly two years later. Thoughts?

A post from the original thread:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/1511

-Kirk McDonald
May 20 2006
next sibling parent Rémy Mouëza <Rémy_member pathlink.com> writes:
In article <e4o55p$20g$1 digitaldaemon.com>, Kirk McDonald says...

Python does exactly this. Like D (and Java, for that matter), class 
instances can only be created by reference, meaning the new keyword is 
redundant, and so the language dropped it entirely. I never understood 
why Java bothered to keep it, and I still don't get it in D. It's still 
useful for structs, which can be put on the stack, yes? So I think D 
should support both syntaxes.


In the Python expression "ojbect = ClassName ()", ClassName is a meta class
object on wich one calls the __call__ method that is the opCall equivalent. This
methode will call the __new__ method that allocates a new object, inits its
primary fields: class name, super classes, dictionnary of methods and
attributes. Then it calls the __init__ method of that object wich is like the
body of a D constructor. 
D type system is not as developped as Python in meta type information ( or
reflexivity ). If one want to change the allocating behaviour of a class, he/she
has to override the 'new' constructor like method in the class. In Python this
would be done in the meta class, with the __new__ method. 
That's why I think that the 'new' keyword still make sense in D.


Because there is only one way to instantiate a class, all of these 
different syntaxes mean the same thing. The "new" keyword is not needed, 
but should still be kept. And if the various Python code I've read is 
any guide, dropping the "new" keyword is still eminently clear for the 
reader.


I agree. 


As far as I could tell, the original thread never really came to a 
conclusion. I was wondering what the D community thought of it now, 
almost exactly two years later. Thoughts?


Keeping the 'new' keyword allows to change the allocation behaviour of class,
passing some arguments to new like: 'new (1, 2, 3 ) World ( "hello");'. As few
people ever modify the allocation behaviour, a factory method like Python would
make an easier to read code without an heavy break of the semantic, but the
static opCall could no more be used for something else than allocation and
initialization.


-Kirk McDonald
May 20 2006
prev sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 SomeClass  sc2();    // reference assigned to GC-allocated instance


would this open up the C++ can-o'-worms that makes sc2 parse as a function 
delcaration instead of a constructor call?
May 22 2006
parent reply Rémy Mouëza <Rémy_member pathlink.com> writes:
In article <e4su89$j7n$1 digitaldaemon.com>, Ben Hinkle says...

 SomeClass  sc2();    // reference assigned to GC-allocated instance


would this open up the C++ can-o'-worms that makes sc2 parse as a function 
delcaration instead of a constructor call? 


Hello Ben. Seems you had disappeared from the forum for a while. How are you ? 

I've tried several times to parse C++ or subsets of it and it appeared that this
kind of syntax is awful to parse. I didn't pay intention to it while reading the
post (maybe because it was quite late in the night). I think this should not be
allowed in D: it would make the grammar ambiguous and therefore would not keep
the language "spirit". 
Otherwise, the allocation "Someclass sc = Someclass ();" is an interesting
suggestion. It could allow very concise code with auto type inference, like:
auto sc = Someclass ();
May 22 2006
parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Rémy Mouëza wrote:

 In article <e4su89$j7n$1 digitaldaemon.com>, Ben Hinkle says...
 

SomeClass  sc2();    // reference assigned to GC-allocated instance


would this open up the C++ can-o'-worms that makes sc2 parse as a function 
delcaration instead of a constructor call? 




[snip]


 Otherwise, the allocation "Someclass sc = Someclass ();" is an interesting
 suggestion. It could allow very concise code with auto type inference, like:
 auto sc = Someclass ();


Heh, I can live without C++-style

     SomeClass sc2();

As for

     auto sc = SomeClass();

that is even closer to how Python does it (it even drops the "auto" as 
it is a dynamically typed language; I don't suggest that here), and 
would be pretty cool to have in D.

-Kirk McDonald
May 22 2006