"D objects are created with the new syntax:
  A a = new A(3);"

This replicates one of my pet peeves. It looks quite standard
and reasonable but I have never created a class named 'A'. More
likely is 'UTIL_New_hash_table_from_list' or some such. The example
is more like:
UTIL_New_hash_table_from_list master_table = new UTIL_New_hash_table_from_list (startval);


Why not eliminate the redundant class name?
A a = new(3);
i.e.
 UTIL_New_hash_table_from_list master_table = new (startval);

The same applies to assignments

a = new (3)    // 'new' determined by a's type

Karl Bochert

"Karl Bochert" <kbochert@ix.netcom.com> wrote in message news:1103_1009927822@bose...

> Why not eliminate the redundant class name?
> A a = new(3);
> i.e.
>  UTIL_New_hash_table_from_list master_table = new (startval);
>
> The same applies to assignments
>
> a = new (3)    // 'new' determined by a's type

Sounds like an interesting and useful idea! I would
really like to see this implemented in D.

Karl Bochert wrote:

> "D objects are created with the new syntax:
>   A a = new A(3);"
> 
>
> Why not eliminate the redundant class name?
> A a = new(3);
> i.e.
>  UTIL_New_hash_table_from_list master_table = new (startval);
> 
> The same applies to assignments
> 
> a = new (3)    // 'new' determined by a's type


The class name on the new side of the assignment still
wants to be optional, at least, for the polymorphic case,
as in:

Vehicle a = new Car;
vehicle_list.add( a );
Vehicle b = new Boat;
vehicle_list.add( b );

-RB

Why not make it a property of class references:

class A
{
  this(int x) {}
}

A a;
a.new(3);  // creates a new A and makes a refer to it.

Sean

"Karl Bochert" <kbochert@ix.netcom.com> wrote in message news:1103_1009927822@bose...
> "D objects are created with the new syntax:
>   A a = new A(3);"
>
> This replicates one of my pet peeves. It looks quite standard
> and reasonable but I have never created a class named 'A'. More
> likely is 'UTIL_New_hash_table_from_list' or some such. The example
> is more like:
> UTIL_New_hash_table_from_list master_table = new
UTIL_New_hash_table_from_list (startval);
>
>
> Why not eliminate the redundant class name?
> A a = new(3);
> i.e.
>  UTIL_New_hash_table_from_list master_table = new (startval);
>
> The same applies to assignments
>
> a = new (3)    // 'new' determined by a's type
>
> Karl Bochert

Good idea, but we need to cover some odd cases:

interface I;
class Parent : public I;
class Child : public Parent;
...
I foo = new Child(3);
Parent bar = new Child(3);
Child baz = new Child(3);

In other words, what happens when the result of new is stored in a base class type?

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C34BAF6.776B3B55@deming-os.org...

> In other words, what happens when the result of new is stored in a base
class type?

In this case, you have to define the classname explicitly (the normal form of new operator). However, since most frequently you want to create a new object and store the result in the variable of the same type, you can use the short form.

"Karl Bochert" <kbochert@ix.netcom.com> escribió en el mensaje
news:1103_1009927822@bose...
| "D objects are created with the new syntax:
|   A a = new A(3);"
|
| This replicates one of my pet peeves. It looks quite standard
| and reasonable but I have never created a class named 'A'. More
| likely is 'UTIL_New_hash_table_from_list' or some such. The example
| is more like:
| UTIL_New_hash_table_from_list master_table = new
UTIL_New_hash_table_from_list (startval);
|
|
| Why not eliminate the redundant class name?
| A a = new(3);
| i.e.
|  UTIL_New_hash_table_from_list master_table = new (startval);
|
| The same applies to assignments
|
| a = new (3)    // 'new' determined by a's type
|
| Karl Bochert
|
|

I must say I like it. Walter never said anything on (or is it in? damn prepositions...) this thread...

-------------------------
Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.463 / Virus Database: 262 - Release Date: 2003-03-17

There's a slight problem with it. I first wondered why you have to write the class name both at declaration and at initialisation, but then it became evident to me: given i want to store a list of strings. I want its type to be TStrings which is an abstract collection of strings and can't be instantiated. However, i'm not exactly sure how they should be stored. It can be later initialised with TStringList which is an array of strings, or possibly TSringsFromResource or even TStringsFromHardware or TDOSVariables and such nonsense. :) Whatever inherits it.

This could however be done in some cases... Especially in the case of object-like structs, and sometimes in the case of objects. If it doesn't break the parser too much. But i soehow think that if it would ever be done, it's the last feature to do.

-i.

Carlos Santander B. wrote:
> "Karl Bochert" <kbochert@ix.netcom.com> escribió en el mensaje
> news:1103_1009927822@bose...
> | "D objects are created with the new syntax:
> |   A a = new A(3);"
> |
> | This replicates one of my pet peeves. It looks quite standard
> | and reasonable but I have never created a class named 'A'. More
> | likely is 'UTIL_New_hash_table_from_list' or some such. The example
> | is more like:
> | UTIL_New_hash_table_from_list master_table = new
> UTIL_New_hash_table_from_list (startval);
> |
> |
> | Why not eliminate the redundant class name?
> | A a = new(3);
> | i.e.
> |  UTIL_New_hash_table_from_list master_table = new (startval);
> |
> | The same applies to assignments
> |
> | a = new (3)    // 'new' determined by a's type
> |
> | Karl Bochert
> |
> |
> 
> I must say I like it. Walter never said anything on (or is it in? damn
> prepositions...) this thread...

Your prepositions are OK. You just have to become clear about what you want to say. :>

"Ilya Minkov" <midiclub@8ung.at> escribió en el mensaje
news:b5kpd2$1cs0$1@digitaldaemon.com...
| There's a slight problem with it. I first wondered why you have to write
| the class name both at declaration and at initialisation, but then it
| became evident to me: given i want to store a list of strings. I want
| its type to be TStrings which is an abstract collection of strings and
| can't be instantiated. However, i'm not exactly sure how they should be
| stored. It can be later initialised with TStringList which is an array
| of strings, or possibly TSringsFromResource or even TStringsFromHardware
| or TDOSVariables and such nonsense. :) Whatever inherits it.
|
| This could however be done in some cases... Especially in the case of
| object-like structs, and sometimes in the case of objects. If it doesn't
| break the parser too much. But i soehow think that if it would ever be
| done, it's the last feature to do.
|
| -i.

Already answered:

"Pavel Minayev" <evilone@omen.ru> escribió en el mensaje
news:a12e9o$r2j$1@digitaldaemon.com...
| "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message
| news:3C34BAF6.776B3B55@deming-os.org...
|
| > In other words, what happens when the result of new is stored in a base
| class type?
|
| In this case, you have to define the classname explicitly (the
| normal form of new operator). However, since most frequently
| you want to create a new object and store the result in the
| variable of the same type, you can use the short form.
|
|

-------------------------
Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.463 / Virus Database: 262 - Release Date: 2003-03-17

In article <b5kpd2$1cs0$1@digitaldaemon.com>, midiclub@8ung.at says...
> There's a slight problem with it. I first wondered why you have to write the class name both at declaration and at initialisation, but then it became evident to me: given i want to store a list of strings. I want its type to be TStrings which is an abstract collection of strings and can't be instantiated. However, i'm not exactly sure how they should be stored. It can be later initialised with TStringList which is an array of strings, or possibly TSringsFromResource or even TStringsFromHardware or TDOSVariables and such nonsense. :) Whatever inherits it.
> 
> This could however be done in some cases... Especially in the case of object-like structs, and sometimes in the case of objects. If it doesn't break the parser too much. But i soehow think that if it would ever be done, it's the last feature to do.
> 

  I also find it personally annoying that I have to keep on restating my
intent in most class declarations.

  And one does not have to demand that a shorter form of the syntax has
to be used..

  A x; // x is uninitialized
  A x1(); // x1 is one instance of A
  A x2= new B; // x2 is one instance of B

  I'm also of the opinion that the current difference between structs
and classes should be relegated to a declaration attribute, but hey, I'm
wacky..

-- 
 - Factory, there is no X in my email.