I've always wondered about the requirement of the word new in Java.  It appears Java (I don't know much about it) pretends there are no references/pointers to help the poor coder who can't handle it (so I've read as the reason):

   Airplane A = new Airplane();
   // work with A

   // Make a new Airplane for the following function
   Fly( new Airplane( bar, 3 ) );

    Airplane B;
    // dont' work with B yet or a run-time error occurs

So, with such an emphasis on "no pointers" and coddling the pre-school coder, why the use of the word new?  It feels very pointer'ish to me. Forgetting it would cause a strange thing called a bad reference.  Scary! Why not

   Airplane A;
   // use default airplane

   Airplane A = Airplane( 3 );
   // use specially constructed airplane
   // could have also just been a regular function like A = Init( 3 );

   // Make a new Airplane for the following function
   Fly( Airplane( bar, 3 ) );

This "new" practice has been copied to javascript, php, and now D.  Why? And before you hit me up with an efficiency issue, well OK, but these languages aren't bastions of efficiency and so why leave a possible run-time error hanging?

Because, imho, constructors do things and moreover sometimes don't exist.  Your example would only not compile if Airplane had no constructor that took zero arguments.  Consider this code:

Airplane A;
try
   A = airport.getAirplane(AIRPLANE_FLYING);
catch (AirplaneHasCrashedException)
   A = airport.getAirplane(AIRPLANE_GROUND);

Okay, a dumb example I'm sure, but I think it illustrates the point.  I would be REQUIRED to add a dummy constructor, and a PUBLIC dummy constructor no less, to the Airplane class for that code to work under your example.

New, especially to Java and PHP users, definitely doesn't mean anything to do with pointers.  I write PHP software, actually, so I could definitely find you competent PHP programmers (meaning, ones who can write fairly well, not the best in the world, mind you) who have no idea what a pointer is.  PHP does not really use pointers, it uses reference counting all behind the scenes.  Most PHP programmers don't totally even understand explicit references.

-[Unknown]


> I've always wondered about the requirement of the word new in Java.  It appears Java (I don't know much about it) pretends there are no references/pointers to help the poor coder who can't handle it (so I've read as the reason):
> 
>    Airplane A = new Airplane();
>    // work with A
> 
>    // Make a new Airplane for the following function
>    Fly( new Airplane( bar, 3 ) );
> 
>     Airplane B;
>     // dont' work with B yet or a run-time error occurs
> 
> So, with such an emphasis on "no pointers" and coddling the pre-school coder, why the use of the word new?  It feels very pointer'ish to me. Forgetting it would cause a strange thing called a bad reference.  Scary! Why not
> 
>    Airplane A;
>    // use default airplane
> 
>    Airplane A = Airplane( 3 );
>    // use specially constructed airplane
>    // could have also just been a regular function like A = Init( 3 );
> 
>    // Make a new Airplane for the following function
>    Fly( Airplane( bar, 3 ) );
> 
> This "new" practice has been copied to javascript, php, and now D.  Why? And before you hit me up with an efficiency issue, well OK, but these languages aren't bastions of efficiency and so why leave a possible run-time error hanging?
> 
> 

> Airplane A;
> try
>    A = airport.getAirplane(AIRPLANE_FLYING);
> catch (AirplaneHasCrashedException)
>    A = airport.getAirplane(AIRPLANE_GROUND);
>
> Okay, a dumb example I'm sure, but I think it illustrates the point.  I would be REQUIRED to add a dummy constructor, and a PUBLIC dummy constructor no less, to the Airplane class for that code to work under your example.

Good one!  But I can claim that if you don't have a default constructor, then "Airplane A;" is a compile time error.  This would avoid the 'new' keyword.

Well, for one thing, Airplane() could be a function or method; if there's a new in front of it, you immediately know that it's a class. (and code obviousness is rather important, if you ask me; quite a lot of projects are worked on by more than one person...).

Plus, in many cases you don't want an object immediately, but at some point in the future (think lazy initialization). How would you handle that?


xs0

PS: What's wrong with D's efficiency?


Charlie Patterson wrote:
>>Airplane A;
>>try
>>   A = airport.getAirplane(AIRPLANE_FLYING);
>>catch (AirplaneHasCrashedException)
>>   A = airport.getAirplane(AIRPLANE_GROUND);
>>
>>Okay, a dumb example I'm sure, but I think it illustrates the point.  I would be REQUIRED to add a dummy constructor, and a PUBLIC dummy constructor no less, to the Airplane class for that code to work under your example.
> 
> 
> Good one!  But I can claim that if you don't have a default constructor, then "Airplane A;" is a compile time error.  This would avoid the 'new' keyword.
> 
> 

"xs0" <xs0@xs0.com> wrote in message news:cuggsr$2u8a$1@digitaldaemon.com...
> Well, for one thing, Airplane() could be a function or method; if there's a new in front of it, you immediately know that it's a class. (and code obviousness is rather important, if you ask me; quite a lot of projects are worked on by more than one person...).
>
> Plus, in many cases you don't want an object immediately, but at some point in the future (think lazy initialization). How would you handle that?

Yeah, I guess you'd have to have a rule that you can't name a function the same as an object name.  Then again, if I wanted to initialize a class with some non-member function, why couldn't I?  Or you could take the tact that I believe D does and have

    Airplane A = this( 3 );
    Airplane B;

   b = this();

Now "this()" is a reserved function and you know what is going on when you see it.

As for your second point, about lazy initialization: I don't see why garbage collected languages care that much.  It seems ease of understanding and coding take the front seat and efficiency loss can be tolerated.  A smarter compiler could wait to use a default constructor when the object it first used, perhaps?

    Airplane A; // no constructor; saves time

    A.rotor = ROTOR_PROP; // first use, sneak in a default constructor.

Just ideas.

"xs0" <xs0@xs0.com> wrote in message news:cuggsr$2u8a$1@digitaldaemon.com...
> PS: What's wrong with D's efficiency?

I'm not proficient in D in the slightest so I'm not sure how much D does or doesn't care about extreme efficiency.  Although I have seen the benchmarks that beat C on some things, so I guess it is considered important.  I was just talking off topic.

I like the idea.

-Craig

I think this idea has merit. However.. it's getting later in the game and something this fundamental will break existing code.

On Thu, 10 Feb 2005 21:41:08 +0100, xs0 <xs0@xs0.com> wrote:
> Well, for one thing, Airplane() could be a function or method; if there's a new in front of it, you immediately know that it's a class. (and code obviousness is rather important, if you ask me; quite a lot of projects are worked on by more than one person...).

Why does it matter whether it's a constructor or a free function, both are returning an Airplane.

If both the function name and object returned are the same then it's a constructor, otherwise it's not. This assumes functions cannot be named the same as an object, which I believe is the case already.

> Plus, in many cases you don't want an object immediately, but at some point in the future (think lazy initialization). How would you handle that?

Airplane A = null;

If you assume that it's more likely you want to construct something than not, then this is no chore.

It also means that if the programmer intends not to construct something they actually have to say so. So, as the OP mentions you can't forget to construct it, you can only forget not to, meaning you trade a possible runtime crash (or compile time error) for a potentially negligible performance hit.

> PS: What's wrong with D's efficiency?

It's pretty good and is likely to improve. Unless, we trade some of it off for more advanced features, hopefully there is a way to have both.

Regan

> Charlie Patterson wrote:
>>> Airplane A;
>>> try
>>>   A = airport.getAirplane(AIRPLANE_FLYING);
>>> catch (AirplaneHasCrashedException)
>>>   A = airport.getAirplane(AIRPLANE_GROUND);
>>>
>>> Okay, a dumb example I'm sure, but I think it illustrates the point.  I would be REQUIRED to add a dummy constructor, and a PUBLIC dummy constructor no less, to the Airplane class for that code to work under your example.
>>   Good one!  But I can claim that if you don't have a default constructor, then "Airplane A;" is a compile time error.  This would avoid the 'new' keyword.
>>

Again, this is just my opinion, but you're ignoring that constructors do things again!  Consider this:

// Default constructor for Backup loads all the data from /var/airport into memory.
Backup back;

foreach (char[] file; listfiles("/var/airport"))
   remove(file);

back.SaveBackup();

Another dumb example, but it illustrates my point again, I think.  And I know you'll come back and say, well, you'd just do this:

Backup back = Backup();

To force the constructor to be run, but... still.... it's confusing.

Anyway, getting rid of new would also make D less comfortable for C/C++ users, which is one thing it's seemed to push...

As for this(), it's less searchable imho.  A lot of programmers use tools like lxr, and being able to search for constructor usage is a Good Thing.

-[Unknown]


> As for your second point, about lazy initialization: I don't see why garbage collected languages care that much.  It seems ease of understanding and coding take the front seat and efficiency loss can be tolerated.  A smarter compiler could wait to use a default constructor when the object it first used, perhaps?
> 
>     Airplane A; // no constructor; saves time
> 
>     A.rotor = ROTOR_PROP; // first use, sneak in a default constructor.
> 
> Just ideas.

> Yeah, I guess you'd have to have a rule that you can't name a function the same as an object name.

Still, AFAIK, that would break the context-freeness of D's grammar, which Walter stated as one of the design goals of the language.


> Then again, if I wanted to initialize a class with some non-member function, 
> why couldn't I?  Or you could take the tact that I believe D does and
> have
> 
>     Airplane A = this( 3 );
>     Airplane B;
> 
>    b = this();

That's even worse. this primarily refers to the object instance in a method (i.e. void setX(double x) { this.x=x; }), not to the constructor..


> Now "this()" is a reserved function and you know what is going on when you see it.

Sure, you do now. With your semantics you wouldn't..


> As for your second point, about lazy initialization: I don't see why garbage collected languages care that much.  It seems ease of understanding and coding take the front seat and efficiency loss can be tolerated.  

What does lazy initialization have to do with languages? It's just a common programming technique. Anyhow, consider for example a cache or pool of something; how would you initialize it non-lazily?



> A smarter compiler could wait to use a default constructor when the object 
> it first used, perhaps?
> 
>     Airplane A; // no constructor; saves time
> 
>     A.rotor = ROTOR_PROP; // first use, sneak in a default constructor.

What if it's constructed somewhere else? And usually, if a null is accessed, it's an error that should not be ignored by constructing the object (btw, this would also mean that practically every object access would need the null check)..


xs0