Rehashing NEW keyword a SECOND time, right NOW...

[Larry Serflaten]

I read with interest Carl Franklin's recent (June/01) VBPJ article on .Net Strings.

There is something brought out in his article that I have been questioning
for some time. I wonder why there is an over abundant use of the New
keyword. For example, from Carl's test program (only relavent code from
listing 2 is shown):

Dim Interval As Microsoft.VisualBasic.DateInterval
Dim StartTime As Date
....

Interval = DateInterval.Second
....
StartTime = New Date().Now

In his explaination of StartTime Carl says assigning a value to variable
at the same time it is created is a great feature of .Net. OK, but how
is the Interval variable different from the StartTime variable?

The question I have is that one uses New, and the other does not, even
while there is no real distinction between them when they are dimensioned.

I feel their similatites will lead to confusion as to when one form is used,
compared to the other. Note that under normal circumstances the two
lines could look like:

Dim Interval As DateInterval
Dim StartTime As Date

Carl's specifies the scope to make a point in the article, but for most uses,
the above would be the normal declaration.

The real question I wanted to address, one that I have sent feedback to MS
on, is why the New keyword is needed for the creation of a new object? Unless
I am mistaken, every reference to a base class will create a new object.

In Carl's article we have a variable that is of the Date type, and we want to
assign a date to it. This is a lot like the other variable which is a DateInterval type
except we want to assign a DateInterval to it. Nowhere (looking at the code) does
it inform the programmer that one is an object and the other a member of a structure.
(IE: a constant)

I feel this will be a cause of confusion, and wonder why the New keyword
is actually needed for the object types. For example, if I create a Person class,
then define a variable of the Person type, and later assign a Person object to the
variable, what advantage does the New keyword offer?

'Acceptable now
'Dim Customer As Person = New Person 'or, more simply;
Dim Customer As New Person

Customer = NextCustomer


'Why not this?
Dim Customer As Person

Customer = NextCustomer

I see the New keyword popping up all over the place in VB.Net code, including
in parameters to functions. In Carl's article, the opportunity for confusion is
demonstrated, one variable used New and the other did not.

Do we really need the New keyword at all? The Set keyword was dropped because
all object assignments are now explicit object assignments, and not some default
property. Could we not drop the New keyword for similar reasons, that all references
to a named base class require a call to the base's New routine (constructor)?

Is there a case where "= Person" would be used, without having to first create a new
Person object?

LFS

[Daniel Pratt]

Hi Larry,

Regarding this line of code:

StartTime = New Date().Now

I'm surprised that the VB compiler allows this. Unless I'm missing
something, the "New" is completely superfluous here. "Now" is a shared
method, which is to say that it does not require an instance of the Date
structure.
Interestingly, C# does not allow you to access static methods or
properties using variable names. You must use the class name, as in:

StartTime = Date.Now

Regarding your suggestion of dropping "New" all together, I am somewhat
confused. Are you suggesting that objects are created thus?:

Dim Customer As Person
...
Customer = Person

'or perhaps

Customer = Person(...)

My only beef with this is that currently you can create variables with
the same name as the class, such as:

Dim Customer As Person
Dim Person As Person

...

Customer = Person ' what am I doing here?

Don't you think the other Dan has enough to complain about :-)

Finally, it is not true that any reference to a base class will create a
new instance of that class as necessary. Structures do behave this way,
however. Before Structures and Enums had methods, the distinction was easier
to make. Now it can get confusing.

Regards,
Dan

"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:3b252598@news.devx.com...
> I read with interest Carl Franklin's recent (June/01) VBPJ article on .Net
Strings.
>
> There is something brought out in his article that I have been questioning
> for some time. I wonder why there is an over abundant use of the New
> keyword. For example, from Carl's test program (only relavent code from
> listing 2 is shown):
>
> Dim Interval As Microsoft.VisualBasic.DateInterval
> Dim StartTime As Date
> ...
>
> Interval = DateInterval.Second
> ...
> StartTime = New Date().Now
>
> In his explaination of StartTime Carl says assigning a value to variable
> at the same time it is created is a great feature of .Net. OK, but how
> is the Interval variable different from the StartTime variable?
>
> The question I have is that one uses New, and the other does not, even
> while there is no real distinction between them when they are dimensioned.
>
> I feel their similatites will lead to confusion as to when one form is
used,
> compared to the other. Note that under normal circumstances the two
> lines could look like:
>
> Dim Interval As DateInterval
> Dim StartTime As Date
>
> Carl's specifies the scope to make a point in the article, but for most
uses,
> the above would be the normal declaration.
>
> The real question I wanted to address, one that I have sent feedback to MS
> on, is why the New keyword is needed for the creation of a new object?
Unless
> I am mistaken, every reference to a base class will create a new object.
>
> In Carl's article we have a variable that is of the Date type, and we want
to
> assign a date to it. This is a lot like the other variable which is a
DateInterval type
> except we want to assign a DateInterval to it. Nowhere (looking at the
code) does
> it inform the programmer that one is an object and the other a member of a
structure.
> (IE: a constant)
>
> I feel this will be a cause of confusion, and wonder why the New keyword
> is actually needed for the object types. For example, if I create a
Person class,
> then define a variable of the Person type, and later assign a Person
object to the
> variable, what advantage does the New keyword offer?
>
> 'Acceptable now
> 'Dim Customer As Person = New Person 'or, more simply;
> Dim Customer As New Person
>
> Customer = NextCustomer
>
>
> 'Why not this?
> Dim Customer As Person
>
> Customer = NextCustomer
>
> I see the New keyword popping up all over the place in VB.Net code,
including
> in parameters to functions. In Carl's article, the opportunity for
confusion is
> demonstrated, one variable used New and the other did not.
>
> Do we really need the New keyword at all? The Set keyword was dropped
because
> all object assignments are now explicit object assignments, and not some
default
> property. Could we not drop the New keyword for similar reasons, that all
references
> to a named base class require a call to the base's New routine
(constructor)?
>
> Is there a case where "= Person" would be used, without having to first
create a new
> Person object?
>
> LFS
>
>
>

[Tom Barnaby]

"Larry Serflaten" <serflaten@usinternet.com> wrote:
>
>Dim Interval As Microsoft.VisualBasic.DateInterval
>Dim StartTime As Date
>....
>
>Interval = DateInterval.Second
>....
>StartTime = New Date().Now
>

>In his explaination of StartTime Carl says assigning a value to variable
>at the same time it is created is a great feature of .Net. OK, but how
>is the Interval variable different from the StartTime variable?
>

The difference is that Interval is typed to a value type (DateInterval),
and StartTime is typed to a reference type (Date). Behind the scenes, the
Date type is mapped to the DateTime class defined by the CLR.

There are many differences between value types and reference types, a key
one being that you do not have to "New" value types. The runtime will allocate
them automatically on the stack.

Furthermore this part of the code snippet is really bizarre:

StartTime = New Date().Now

The Now method is a static method on the DateTime class. Therefore, an instance
of DateTime is not required in order to call the method. The following line
would be just as effective, and probably more efficient:

StartTime = Date.Now

The static (or in vb parlance "Shared") Now method creates and returns a
reference to a DateTime object. Since the method creates the object for you
, you don't have to explicitly do so with "New".

>The question I have is that one uses New, and the other does not, even
>while there is no real distinction between them when they are dimensioned.
>
>I feel their similatites will lead to confusion as to when one form is used,
>compared to the other. Note that under normal circumstances the two
>lines could look like:
>
>Dim Interval As DateInterval
>Dim StartTime As Date
>
>Carl's specifies the scope to make a point in the article, but for most
uses,
>the above would be the normal declaration.
>
>The real question I wanted to address, one that I have sent feedback to
MS
>on, is why the New keyword is needed for the creation of a new object?
Unless
>I am mistaken, every reference to a base class will create a new object.
>

You are mistaken. ;-)

Somewhere the object must be instantiated with the New keyword. It just so
happens that the Now() method does that for you.

>In Carl's article we have a variable that is of the Date type, and we want
to
>assign a date to it. This is a lot like the other variable which is a DateInterval
>type
>except we want to assign a DateInterval to it. Nowhere (looking at the
code) does
>it inform the programmer that one is an object and the other a member of
a structure.
>(IE: a constant)
>

I can also see the potential for confusion. If it makes you feel better,
you can also "New" value types e.g:

Dim i as Integer = New Integer()

That removes the inconsistency, but I doubt it is a convention that will
catch on.

Sorry - I'd like to address the other questions, but I gotta go back to class!

Tom Barnaby
www.intertech-inc.com

[Larry Serflaten]

"Daniel Pratt" <dprREMOVETHISatt71@hotmail.com> wrote


> My only beef with this is that currently you can create variables with
> the same name as the class, such as:
>
> Dim Customer As Person
> Dim Person As Person
>
> ...
>
> Customer = Person ' what am I doing here?

You are confusing yourself <g> by using a local variable of the same name as
a project-wide class name. You would be assigning a reference value from
the local Person variable, to the Customer variable. If you want to avoid that
confusion, don't use local variables that are named like the variables in a
larger scope. In fact, I believe I read this as a 'good coding practise', but
would have to go find it, to be sure...


> Finally, it is not true that any reference to a base class will create a
> new instance of that class as necessary.

Example? Remember, I am interested in only the case where "= <className>" is used.

> Structures do behave this way,
> however. Before Structures and Enums had methods, the distinction was easier
> to make. Now it can get confusing.

There you have it. Why cannot the objects be used in much the same manner
as structures? Having one require New, will be a source of confusion IMO.

The point is that we are now using objects left and right, causing too much use
of the New keyword. It seems superfluous....

LFS

[Larry Serflaten]

"Tom Barnaby" <tbarnaby@intertech-inc.com> wrote

> The difference is that Interval is typed to a value type (DateInterval),
> and StartTime is typed to a reference type (Date). Behind the scenes, the
> Date type is mapped to the DateTime class defined by the CLR.

That's the underlying implementation, something VB has to deal with...

>
> There are many differences between value types and reference types, a key
> one being that you do not have to "New" value types. The runtime will allocate
> them automatically on the stack.

The question is why not treat object references similarily, at the VB level?


>
> Furthermore this part of the code snippet is really bizarre:
>
> StartTime = New Date().Now
>
> The Now method is a static method on the DateTime class. Therefore, an instance
> of DateTime is not required in order to call the method. The following line
> would be just as effective, and probably more efficient:
>
> StartTime = Date.Now

I didn't write the code, I used it as an example where it both methods were used <g>!
In fact, I did not question it, in that it served my purpose so as to be an example of the
confusion that might develop. I think MS should be able to drop the New keyword, (as
they did with Set - Gosub, etc.) and I have yet to see/hear why they cannot.

> Unless
> >I am mistaken, every reference to a base class will create a new object.
> >
>
> You are mistaken. ;-)

Do you know of an example where "= <className>" is used, that will not be creating
a new instance? I could not think of any....



> Somewhere the object must be instantiated with the New keyword. It just so
> happens that the Now() method does that for you.

Why can not the New keyword be implicit? Why must it be present?


> I can also see the potential for confusion. If it makes you feel better,
> you can also "New" value types e.g:
>
> Dim i as Integer = New Integer()
>
> That removes the inconsistency, but I doubt it is a convention that will
> catch on.

Precisely my point, there is already too much use of the New keyword, and
this would only add to that. I am looking to have it dropped from the language,
as they did with Set.

> Sorry - I'd like to address the other questions, but I gotta go back to class!

Sure, run off when we get to the heart of the matter! <g>

LFS

[Patrice Scribe]

>
> Why can not the New keyword be implicit? Why must it be present?
>

To be able to discrimate beetween :

Person = SomeOne (SomeOne is an object variable).

Person = New SomeOneClass( SomeOne is a class).

If "New" is not needed you'll have to use :

Person = SomeOne
Person = SomeOneClass

Obvioulsy it would be really easy to get a clean compile even if the code
you wrote is not what you actually intended to do...

Patrice Scribe

[Michael Welch]

Larry,

>
> The question is why not treat object references similarily, at the VB
level?
>

I think another reason is that you don't always want an instance created
when you are declaring a variable.

You don't know how "expensive" it will be to create the instance. It may
have a large constructor grabbing lots of resources. If you are only
declaring a variable that you will use to reference an existing object or to
reference an object that is returned by a method like the Now method, why
would you want to incure the extra overhead of instantiating and object that
you will never use?

Michael

[Daniel Pratt]

Hi Larry,

I'm not sure I entirely understand your suggestion, but if you are
suggesting that VB.NET simply omit the New keyword, then I have a few
problems with that:

1. I don't think it clarifies anything with regard to enumerations
and structures (quite the reverse, I'd say). Object references require
explicit initialization, whereas structures/enums do not. In other words,
you can access the individual fields/methods/properties of structure
variables without setting the variable to a "new" instance of the structure.
IMHO, this would be the potential source of confusion, and I don't see how
eliminating "New" would alleviate it.

2. I think you lose some code clarity. When I see "New..." without
any other context, I know that a new instance of "..." is being created. In
the absence of the "New" keyword, I have to hunt down "..." to find out what
it is.

3. I think the .NOT-ers have enough to complain about, don't you?
:-) In fact, I'm half expecting Karl or Dan B. to express their sarcastic
approval of your proposal :-)

If I'm not understanding, please enlighten me.

Regards,
Dan

"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:3b262100@news.devx.com...
>
> "Daniel Pratt" <dprREMOVETHISatt71@hotmail.com> wrote
>
>
> > My only beef with this is that currently you can create variables
with
> > the same name as the class, such as:
> >
> > Dim Customer As Person
> > Dim Person As Person
> >
> > ...
> >
> > Customer = Person ' what am I doing here?
>
> You are confusing yourself <g> by using a local variable of the same name
as
> a project-wide class name. You would be assigning a reference value from
> the local Person variable, to the Customer variable. If you want to avoid
that
> confusion, don't use local variables that are named like the variables in
a
> larger scope. In fact, I believe I read this as a 'good coding practise',
but
> would have to go find it, to be sure...
>
>
> > Finally, it is not true that any reference to a base class will
create a
> > new instance of that class as necessary.
>
> Example? Remember, I am interested in only the case where "= <className>"
is used.
>
> > Structures do behave this way,
> > however. Before Structures and Enums had methods, the distinction was
easier
> > to make. Now it can get confusing.
>
> There you have it. Why cannot the objects be used in much the same manner
> as structures? Having one require New, will be a source of confusion IMO.
>
> The point is that we are now using objects left and right, causing too
much use
> of the New keyword. It seems superfluous....
>
> LFS
>
>

[Larry Serflaten]

"Patrice Scribe" <scribe@chez.com> wrote

> > Why can not the New keyword be implicit? Why must it be present?

> To be able to discrimate beetween :
>
> Person = SomeOne (SomeOne is an object variable).
> Person = New SomeOneClass( SomeOne is a class).
>
> If "New" is not needed you'll have to use :
>
> Person = SomeOne
> Person = SomeOneClass
>

It looks to me like you just dropped the New keyword. That is exactly what I
am suggesting. If you meant that VB would have a hard time telling the
difference between a local "Someone" variable and a project wide "Someone"
reference, that's the programmer's fault, using conflicting names.... the local
variable (reference object) would be used.

LFS

> Obvioulsy it would be really easy to get a clean compile even if the code
> you wrote is not what you actually intended to do...

You lost me...

LFS

[Larry Serflaten]

"Daniel Pratt" <dprREMOVETHISatt71@hotmail.com> wrote
> Hi Larry,
>
> I'm not sure I entirely understand your suggestion, but if you are
> suggesting that VB.NET simply omit the New keyword, then I have a few
> problems with that:
>
> 1. I don't think it clarifies anything with regard to enumerations
> and structures (quite the reverse, I'd say). Object references require
> explicit initialization, whereas structures/enums do not.

Nearly everything used, is an object. Some require a New sub, others do not.
Why reflect that fact back to the language?

In other words, the docs say: "In Visual Basic.NET 7.0, there is no implicit object creation."

And I wonder why not...


>
> 2. I think you lose some code clarity. When I see "New..." without
> any other context, I know that a new instance of "..." is being created. In
> the absence of the "New" keyword, I have to hunt down "..." to find out what
> it is.

If your "..." was "CashDrawer", would you really have to go look to find out what it is?
IOW the naming convention should be used to help readability....

>
> 3. I think the .NOT-ers have enough to complain about, don't you?
> :-) In fact, I'm half expecting Karl or Dan B. to express their sarcastic
> approval of your proposal :-)
>
> If I'm not understanding, please enlighten me.

OK, so we now mark it as 'Depreciated' and work towards its removal in future versions....
Remember, Let had its place in the language at one time too, if Let is implicit
then New should be. If either one is needed, why not Let? (Too much use, right?)

I think it would be possible to depreciate it, just to try it out!

LFS

[Larry Serflaten]

"Michael Welch" <michaelgwelchathotmailnospam.com> wrote
> >
>
> I think another reason is that you don't always want an instance created
> when you are declaring a variable.

OK, so you get two forms:

Dim Foo As Bar ' Without creation
Dim Foo As Bar = Bar 'With

>
> You don't know how "expensive" it will be to create the instance

So don't create it until it is needed...

LFS

[Michael Welch]

Sorry,

I misunderstood your point.

I thought you were saying

Dim Foo as Bar

should automatically create the object.

nevermind.

Michael

[Joe \Nuke Me Xemu\ Foster]

"Larry Serflaten" <serflaten@usinternet.com> wrote in message <news:3b2645c4@news.devx.com>...

> "Daniel Pratt" <dprREMOVETHISatt71@hotmail.com> wrote
> > Hi Larry,
> >
> > I'm not sure I entirely understand your suggestion, but if you are
> > suggesting that VB.NET simply omit the New keyword, then I have a few
> > problems with that:
> >
> > 1. I don't think it clarifies anything with regard to enumerations
> > and structures (quite the reverse, I'd say). Object references require
> > explicit initialization, whereas structures/enums do not.
>
> Nearly everything used, is an object. Some require a New sub, others do not.
> Why reflect that fact back to the language?

What should something like this snippet do? Would it depend on whether
mything1 and mything2 are objects or UDTs? Should Set also go away?

dim mything1 as mything, mything2 as mything
mything1.myinteger = 1
mything2 = mything1
mything2.myinteger = 2
messagebox mything1.myinteger.tostring

What if we have a really "large" class? Should we simply not define
objects of that type until we're ready to initialize them? What if
instances are passed back in a ByRef parameter to a sub or method, if
such things are even still allowed? You'd then have a chunk of memory
going AWOL until the next GC, and for what?

Dim myreallybigthing As reallybigthing ' = nothing ' to prevent auto-New?
WhyDidntTheyMakeThisAFunction myreallybigthing

Now we want to get rid of it and create a brand-new one:

Set myreallybigthing = Nothing ' OK so far
Set myreallybigthing = New reallybigthing("uh-oh, now what?")

--
Joe Foster <mailto:jfoster@ricochet.net> Got Thetans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Joe \Nuke Me Xemu\ Foster]

"Larry Serflaten" <serflaten@usinternet.com> wrote in message <news:3b2647c1@news.devx.com>...

> "Michael Welch" <michaelgwelchathotmailnospam.com> wrote
> > >
> >
> > I think another reason is that you don't always want an instance created
> > when you are declaring a variable.
>
> OK, so you get two forms:
>
> Dim Foo As Bar ' Without creation
> Dim Foo As Bar = Bar 'With

And objects are thus still "different".

--
Joe Foster <mailto:jfoster@ricochet.net> Space Cooties! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Russell Jones]

Joe:

Set *did* go away. Why don't you get a copy of VB.NET and try it?

"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
news:3b26c388@news.devx.com...
> What should something like this snippet do? Would it depend on whether
> mything1 and mything2 are objects or UDTs? Should Set also go away?
>