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


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 5 123 ... LastLast
Results 1 to 15 of 65

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

  1. #1
    Larry Serflaten Guest

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

    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




  2. #2
    Daniel Pratt Guest

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

    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
    >
    >
    >




  3. #3
    Tom Barnaby Guest

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


    "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

  4. #4
    Larry Serflaten Guest

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


    "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



  5. #5
    Larry Serflaten Guest

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


    "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



  6. #6
    Patrice Scribe Guest

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

    >
    > 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



  7. #7
    Michael Welch Guest

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

    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



  8. #8
    Daniel Pratt Guest

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

    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
    >
    >




  9. #9
    Larry Serflaten Guest

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


    "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




  10. #10
    Larry Serflaten Guest

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


    "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




  11. #11
    Larry Serflaten Guest

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


    "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




  12. #12
    Michael Welch Guest

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

    Sorry,

    I misunderstood your point.

    I thought you were saying

    Dim Foo as Bar

    should automatically create the object.

    nevermind.

    Michael



  13. #13
    Joe \Nuke Me Xemu\ Foster Guest

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

    "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!



  14. #14
    Joe \Nuke Me Xemu\ Foster Guest

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

    "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!



  15. #15
    Russell Jones Guest

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

    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?
    >





Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center