Rehashing NEW keyword a SECOND time, right NOW... - Page 2


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 5 FirstFirst 1234 ... LastLast
Results 16 to 30 of 65

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

  1. #16
    Joe \Nuke Me Xemu\ Foster Guest

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

    "Russell Jones" <arj1@northstate.net> wrote in message <news:3b26ea2f$1@news.devx.com>...

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


    This close to Beta 2? Any findings I have to report from B1 will merely
    be met with, "Wait for Beta 2!" while anything I might find with Beta 2
    will merely be met with "Wait for the release!" from the NDA'd. Or I
    could sign the dotted line like Daniel Webster and Be In The Know, but
    also likely be enjoined to stf up at last. Oh boy! Where can I sign up?

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



  2. #17
    Gregor R. Peisker Guest

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

    Hi Larry,

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


    The "New" keyword is needed because of the perhaps most important
    characteristic of classes (besides the usual OO gang of three) in VB and
    VB.NET (and in C#, and Java as well) - *reference_semantics* (TM).

    Because of reference semantics, we have the following keywords: Is, New,
    Nothing, and, in VB6, Set. Not understanding that classes are reference types
    is the cause of many a myth regarding object creation, duplication, reference
    comparison, value comparison, parameter passing mechanisms, and so on.

    Consider the following:

    Sub Test()
    Dim a, b As SomeClass ' create 2 refs
    a = New SomeClass ' create 1 object, assign ref to a
    b = a ' copy ref.
    MySub(a) ' pass reference ByVal
    Dim fRef, fVal As Boolean
    fRef = (a Is b) ' True
    fVal a.CompareTo(b) ' False (needs IComparable)
    b = a.Clone ' copy object (needs ICloneable)
    End Sub
    Sub MySub(ByVal a As SomeClass)
    a.SomeProp = 5 ' update the one and only object so
    ' far, using a copy of the reference
    End Sub

    Here, there's only one object. In fact, there is nothing whatsoever in VB.NET
    code that can be regarded as an object. In this respect, the mantra that
    "everything is an object" sounds all the more dubious. It's all about
    references. VB.NET forces reference semantics on you. Mostly, that suits
    object-oriented programming better: encapsulate the data in one place.

    If you want to choose, use C++ (which offers you value semantics, implicit
    reference semantics with reference variables, or explicit use of pointers).
    You can also use structures, which are light-weight value-type classes (but
    they don't support inheritance, for example).

    Regards,
    Gregor














  3. #18
    Joe \Nuke Me Xemu\ Foster Guest

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

    "Gregor R. Peisker" <gregor@peisker.de> wrote in message <news:3b27a64d@news.devx.com>...

    > If you want to choose, use C++ (which offers you value semantics, implicit
    > reference semantics with reference variables, or explicit use of pointers).
    > You can also use structures, which are light-weight value-type classes (but
    > they don't support inheritance, for example).


    Eh? Structs don't support inheritance? When did this change? In _The C++
    Programming Language Third Edition_ Bjarne Stroustrup ISBN 0-201-88954-4
    section 10.2.8, "By definition, a /struct/ is a class in which members
    are by default public". The grammar in section A.8 supports this. Heck,
    it looks like even *unions* support inheritance! To wit:

    /class-head:/
    /class-key/ /identifier[opt]/ /base-clause[opt]/
    /class-key/ /nested-name-specifier/ /identifier/ /base-clause[opt]/
    /class-key/ /nested-name-specifier/ template /identifier/ /base-clause[opt]/

    /class-key:/
    class
    struct
    union

    Now stand by for that Te(r)d-wit to reply with something completely inane...

    --
    Joe Foster <mailto:jfoster@ricochet.net> DC8s in Spaace: <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!



  4. #19
    Zane Thomas Guest

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

    Joe,

    > Now stand by for that Te(r)d-wit to reply with something completely

    inane...

    I'm going to ask you again to abide by the rules of this forum, as I have
    been for many days. Your continued personal attacks are unnecessary and do
    nothing to contribute to the debate. If you continue then later today or
    tomorrow I'm going to take this issue up with the other section leaders, the
    result could include cancelation of your posts which consistently - day
    after day and hour after hour - violate this forum's rules.

    An occasionaly exhuberant step over the line is typically ignored here. But
    you've been way over the line for a long time.

    Zane




  5. #20
    Zane Thomas Guest

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

    Joe,

    There's a post waiting for your reply on the off.ramp newsgroup.

    Zane




  6. #21
    Larry Serflaten Guest

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


    "Gregor R. Peisker" <gregor@peisker.de> wrote

    > Sub Test()
    > Dim a, b As SomeClass ' create 2 refs
    > a = New SomeClass ' create 1 object, assign ref to a


    >
    > Here, there's only one object. In fact, there is nothing whatsoever in VB.NET
    > code that can be regarded as an object. In this respect, the mantra that
    > "everything is an object" sounds all the more dubious.


    You only have one reference to a base class, aside from the Dim line. That is
    the only one that is created. The others were only references, and you did not
    assign them refering to the base class name.

    Look again, what was the advantage that New offered, that could not be done
    using the base class's name?

    a = SomeClass

    As far as everything being an object, all I can say is; if it walks like a duck, and
    quacks like a duck.... :-)

    LFS






  7. #22
    Ted Guest

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


    Just can't get over can ya dumbass. Unfortunately this jerk off is right Gregor.
    He does one **** of a job reading a ****ing book.

    Gregor,
    you can do this following with structs:

    typedef struct _A
    {
    int x;
    }A;

    typedef struct _B : public A
    {

    }B;

    As for you prick, I would assume with all your knowledge of Star Wars and
    all the other half cocked projects you supposedly worked on would know the
    particulars of structs without reading them. Good job on the ISBN also.
    Can you quote the C++ standard also.


    "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
    >"Gregor R. Peisker" <gregor@peisker.de> wrote in message <news:3b27a64d@news.devx.com>...
    >
    >> If you want to choose, use C++ (which offers you value semantics, implicit
    >> reference semantics with reference variables, or explicit use of pointers).
    >> You can also use structures, which are light-weight value-type classes

    (but
    >> they don't support inheritance, for example).

    >
    >Eh? Structs don't support inheritance? When did this change? In _The C++
    >Programming Language Third Edition_ Bjarne Stroustrup ISBN 0-201-88954-4
    >section 10.2.8, "By definition, a /struct/ is a class in which members
    >are by default public". The grammar in section A.8 supports this. Heck,
    >it looks like even *unions* support inheritance! To wit:
    >
    >/class-head:/
    > /class-key/ /identifier[opt]/ /base-clause[opt]/
    > /class-key/ /nested-name-specifier/ /identifier/ /base-clause[opt]/
    > /class-key/ /nested-name-specifier/ template /identifier/ /base-clause[opt]/
    >
    >/class-key:/
    > class
    > struct
    > union
    >
    >Now stand by for that Te(r)d-wit to reply with something completely inane...
    >
    >--
    >Joe Foster <mailto:jfoster@ricochet.net> DC8s in Spaace: <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!
    >
    >



  8. #23
    Stephen Goguen Guest

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

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


    One characteristic of a good programming language or environment is
    to make things as easy as possible so one can focus thier efforts on
    writing code rather than resolving ambigious statements.

    I would assume that most people would choose to type the three character
    "New", rather than hunting down bugs which are derived from ambiguity.

    The C++ novice and sometimes expect comes across this cute bug...

    if(x = 5) {
    // do something here
    }

    which should be

    if(x == 5) {
    // do something here
    }

    Don't get me wrong, this would probably be a neat feature for another
    language for those who elect to use this paradigm, but for most people
    I think it would cause too many headaches.


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


    In your scenerio as other posters have pointed out:

    Dim Person As Person
    Dim Person2 As Person

    Person2 = Person

    Would compile correctly, but may or may not do what is intended to do,
    much
    like the example I gave above. This isn't the case with the current
    situation as it
    is always clear you're specifying a class name rather than a variable name.

    Personally, If I was going to try to implement your idea, I would
    probably
    denote instantiating an object by adding parenthesis which would include
    class
    names with functions instead of including class names with variable names.

    Ex:

    Dim Person As Person
    Dim Person2 As Person

    'Instantiates a new object
    Person2 = Person()

    'Person2 references Person
    Person2 = Person

    This would allow you to defined variable names that do not conflict with
    objects,
    but your object names now conflict with functions which is certainly a more
    favorable situation than the former.

    Personally, I would still have to favor the New keyword as it clearly
    highlights
    the intended action. However, with some modification and evolution, your
    idea
    may prove to have some merit.

    Steve



  9. #24
    Ted Guest

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


    Appologies to you. Sorry for that.

    "Zane Thomas" <zane@mabry.com> wrote:
    >Ted,
    >
    >> Just can't get over can ya dumbass.

    >
    >We have a place for rants, name-calling, insults and often interesting
    >discussions too. That newsgroup is the off.ramp newsgroup. Please take
    >name-calling and etc there.
    >
    >Zane
    >
    >
    >



  10. #25
    Zane Thomas Guest

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

    Ted,

    > Just can't get over can ya dumbass.


    We have a place for rants, name-calling, insults and often interesting
    discussions too. That newsgroup is the off.ramp newsgroup. Please take
    name-calling and etc there.

    Zane




  11. #26
    Zane Thomas Guest

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

    Ted,

    > Appologies to you. Sorry for that.


    No problem, thanks. We all get a bit carried away once in a while.

    Zane




  12. #27
    Joe \Nuke Me Xemu\ Foster Guest

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

    "Ted" <TTarney@hotmail.com> wrote in message <news:3b27c7ea$1@news.devx.com>...

    > As for you prick, I would assume with all your knowledge of Star Wars and
    > all the other half cocked projects you supposedly worked on would know the
    > particulars of structs without reading them. Good job on the ISBN also.


    Do you deny that had I not already known the particulars of structs, I
    wouldn't have known that bit about structs' not supporting inheritance
    was wrong? Do you deny that providing a cite before having to be asked
    for it saved a little time for everyone involved? The book was nearby,
    and I had to look it up to be certain anyway, so whyever not?

    > Can you quote the C++ standard also.


    Not by heart. That's what reference works are for!

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



  13. #28
    Phil Weber Guest

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

    > if(x = 5) {
    > // do something here
    > }


    Stephen: I've been bitten by that one, but it was JavaScript, not C++.
    Wasted about half a day!
    ---
    Phil Weber



  14. #29
    Zane Thomas Guest

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

    Phil,

    > > if(x = 5) {


    C# doesn't allow that, it gives an "cannot convert int to bool" error.
    Dunno about VB. :-)

    Zane




  15. #30
    Bill McCarthy Guest

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


    "Zane Thomas" <zane@mabry.com> wrote in message
    news:3b2803f1$1@news.devx.com...
    > Phil,
    >
    > > > if(x = 5) {

    >
    > C# doesn't allow that, it gives an "cannot convert int to bool" error.
    > Dunno about VB. :-)
    >


    hehe... yep that one will catch a few VBers going to C#. In C# that should be
    ==
    BTW: in VB.NET you can test for If x =5 Then, but not If x Then




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