Speaking of strings...


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 17 12311 ... LastLast
Results 1 to 15 of 247

Thread: Speaking of strings...

Hybrid View

  1. #1
    Harlow Guest

    Speaking of strings...


    "Jason" <jason@hotmail.com> wrote:
    >
    >Let me be more specific on some of these things:
    >
    >Functions for manipulating strings:
    > Mid$
    > Left$
    > UCase$
    > LCaseS
    > StrConv
    >
    >Why are all these things functions? Because they were functions in Basic
    >20 years ago! My TRS80 Model 100 supports all these functions, using the
    >original version of Microsoft Basic.
    >
    >Strings are objects. Files are objects. But in VB-classic, they are data
    >structures, or something that is not quite an object. Legacy.
    >


    Can anyone tell me why the .NET String class is Sealed (C# term, I don't
    know what the VB.NET equivalent is)? It does not have a Left method for example,
    so why not inherit from the String class and add your own Left functionality?
    I'll tell you why, because it is Sealed. You cannot inherit from it. Is there
    something I am missing?

    - Harlow.

    p.s. - Yes, I know the String class has a SubString method, but it throws
    an exception if you go out of range. The Left implementation would give you
    as many characters as are available without requiring that the caller know
    how many are there.

  2. #2
    blob Guest

    Re: Speaking of strings...


    >Can anyone tell me why the .NET String class is Sealed (C# term, I don't
    >know what the VB.NET equivalent is)? It does not have a Left method for

    example,
    >so why not inherit from the String class and add your own Left functionality?
    >I'll tell you why, because it is Sealed. You cannot inherit from it. Is

    there
    >something I am missing?


    Why inherit? Why not use containment and add your Left function. It would
    wind up something similar to private inheritance in C++. This is what happens
    when VB programmers attempt OO. Inherit, inherit, inherit. Come on you
    (so-called) OO VB developers, let me have it.

  3. #3
    Jason Guest

    Re: Speaking of strings...


    "Harlow" <harlow@nospam.com> wrote:
    >Can anyone tell me why the .NET String class is Sealed (C# term, I don't
    >know what the VB.NET equivalent is)? It does not have a Left method for

    example,
    >so why not inherit from the String class and add your own Left functionality?
    >I'll tell you why, because it is Sealed. You cannot inherit from it. Is

    there
    >something I am missing?
    >
    > - Harlow.


    Probably a speed or size optimization. No inheritance, no virtual function-pointer
    table lookups. Maybe for consistency, since you can't inherit from any of
    the basic data types.

    Java does the same thing.

  4. #4
    Vinay Guest

    Re: Speaking of strings...


    "Harlow" <harlow@nospam.com> wrote:
    >
    >
    >Can anyone tell me why the .NET String class is Sealed


    IMO,
    String is special class in a sense that programmers want to use it as a value
    type. And compilers and CLR also recognize string as special class. CLR has
    lot of optimizations for strings and many of them r possible because CLR
    knows strings are immutable (only access possible is read access). And thats
    why the class is sealed so that no one should inherit it and make it read-write
    turning CLR's main assumption to shreds.

    -Vinay.

  5. #5
    Mike Mitchell Guest

    Re: Speaking of strings...

    On 4 Oct 2002 21:53:58 -0700, "Vinay" <vinayc@angelfire.com> wrote:

    >IMO,
    >String is special class in a sense that programmers want to use it as a value
    >type. And compilers and CLR also recognize string as special class. CLR has
    >lot of optimizations for strings and many of them r possible because CLR
    >knows strings are immutable (only access possible is read access). And thats
    >why the class is sealed so that no one should inherit it and make it read-write
    >turning CLR's main assumption to shreds.



    I'd like to know one good reason why a VB.Net string has to be an
    object.

    MM

  6. #6
    Larry Serflaten Guest

    Re: Speaking of strings...

    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    >
    > I'd like to know one good reason why a VB.Net string has to be an
    > object.


    How about because there were many commands in VB that only worked
    on strings (Left, Right, UCase, LCase, Trim, etc) which would be better
    if they were simply methods of the string class. These are common methods
    mind you, used regularly, so it makes sense to have them as methods on the
    class. So, then, if they made String a value type, that would mean every
    call to one of its methods would included the boxing of the value so that
    the methods could be called. It could be a dramatic performance hit
    if every method had to check for, or create, a boxed object.

    That could be a major reason right there.

    LFS



  7. #7
    Mike Mitchell Guest

    Re: Speaking of strings...

    On Sat, 5 Oct 2002 19:39:51 -0500, "Larry Serflaten"
    <serflaten@usinternet.com> wrote:

    >How about because there were many commands in VB that only worked
    >on strings (Left, Right, UCase, LCase, Trim, etc) which would be better
    >if they were simply methods of the string class.


    Why? What is wrong with functions like Left$, Trim$ etc?

    > These are common methods
    >mind you, used regularly, so it makes sense to have them as methods on the
    >class.


    Why? What is better about a method than a function? Why?

    > So, then, if they made String a value type, that would mean every
    >call to one of its methods would included the boxing of the value so that
    >the methods could be called.


    Or use a function. Again, why is a String now an object? Why?

    > It could be a dramatic performance hit
    >if every method had to check for, or create, a boxed object.


    Of course. Not with a function though. With strings like they used to
    be.

    >That could be a major reason right there.


    Or not.

    MM

  8. #8
    Larry Serflaten Guest

    Re: Speaking of strings...

    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote

    >
    > Why? What is better about a method than a function? Why?



    Wise up Mike. OOP is here to stay. If you want to learn the
    advantages, then I suggest you take it upon yourself to get educated.
    I am not going rehearse explainations you can find yourself.

    LFS



  9. #9
    Mike Mitchell Guest

    Re: Speaking of strings...

    On Sun, 6 Oct 2002 06:08:05 -0500, "Larry Serflaten"
    <serflaten@usinternet.com> wrote:

    >"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote
    >
    >>
    >> Why? What is better about a method than a function? Why?

    >
    >
    >Wise up Mike. OOP is here to stay. If you want to learn the
    >advantages, then I suggest you take it upon yourself to get educated.
    >I am not going rehearse explainations you can find yourself.


    But I am trying to take it upon myself to get educated. You just won't
    tell me what is better about a method! Why keep it a secret? If you
    know, just tell me. Then we'd both know! How about you'll tell me if I
    give you a dollar?

    MM

  10. #10
    Larry Serflaten Guest

    Re: Speaking of strings...

    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote
    > >
    > >Wise up Mike. OOP is here to stay. If you want to learn the
    > >advantages, then I suggest you take it upon yourself to get educated.
    > >I am not going rehearse explainations you can find yourself.

    >
    > But I am trying to take it upon myself to get educated. You just won't
    > tell me what is better about a method! Why keep it a secret? If you
    > know, just tell me. Then we'd both know! How about you'll tell me if I
    > give you a dollar?


    Do you still have your mommy tie your shoes too?

    This is all I am going to offer:
    http://www.google.com/search?hl=en&i...&q=oop+ooa+ood


    LFS



  11. #11
    W.E. (Bill) Goodrich, PhD Guest

    Re: Speaking of strings...

    In article <3da093f1@10.1.10.29>,
    "Larry Serflaten" <serflaten@usinternet.com> writes:

    > "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote


    > > >Wise up Mike. OOP is here to stay.


    LOL!!! Are you really THAT naive? That would help explain a lot.
    No, Larry, OOP is NOT "here to stay" in any meaningful sense. Any
    more than Knuth-style "Strict Structured Programming" was here to
    stay (despite the equally adamant - and naive - claims of its
    supporters). Just as tattered fragments of the '70s fad retain the
    name and little else, a few more years' time will see your beloved
    OOP in a similar state.

    And since you are so found of links:

    http://www.geocities.com/tablizer/oopbad.htm

    http://iraf.noao.edu/iraf/web/ADASS/.../cogginsj.html

    http://www.paulgraham.com/noop.html

    http://www.bluetail.com/~joe/vol1/v1_oo.html


    --

    W.E. (Bill) Goodrich, PhD

    *-----------------------*--------------------------------------------*
    * CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
    * * *
    * Without Aversive * ctgcentral@earthlink.net *
    * Behavior Modification * Creative Technology Group *
    * or Drugs * PO Box 286 *
    * * Englewood, CO 80151-0286 *
    *-----------------------*--------------------------------------------*

  12. #12
    Vinay Guest

    Re: Speaking of strings...


    "Larry Serflaten" <serflaten@usinternet.com> wrote:
    >"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    >>
    >> I'd like to know one good reason why a VB.Net string has to be an
    >> object.

    >
    >How about because there were many commands in VB that only worked
    >on strings (Left, Right, UCase, LCase, Trim, etc) which would be better
    >if they were simply methods of the string class. These are common methods
    >mind you, used regularly, so it makes sense to have them as methods on the
    >class. So, then, if they made String a value type, that would mean every
    >call to one of its methods would included the boxing of the value so that
    >the methods could be called. It could be a dramatic performance hit
    >if every method had to check for, or create, a boxed object.
    >
    >That could be a major reason right there.
    >
    >LFS
    >


    I was not aware of that value types has to be boxed for method invokation.
    Any quick links to documentation?
    Anyway, IMO typically one will want strings on heap and not on stack so why
    bother to make it value type. As far as programmers' perception, compliers
    do make it appear like value type.

    BTW, I don't think .NET strings r different that vb6 strings (BSTR). Both
    were immutable and heap based. Although .NET strings are objects they r perceived
    as value types same as in VB.

    -Vinay

  13. #13
    Miha Markic Guest

    Re: Speaking of strings...

    > I'd like to know one good reason why a VB.Net string has to be an
    > object.
    >
    > MM


    Since every class in .NET is dervied from Object class you instantly get
    Object functionality.
    Also, there is reflection, serialization, etc.
    Why would you have functions since they work only with strings and thus
    belong to strings anyway?

    --
    Miha
    www.spin.si/www/eng



  14. #14
    Brian S Guest

    Re: Speaking of strings...



    For every 4 of your links there are 100 pro OO articles from "recognized"
    and "respected" authorities on the topic. Not these whipped up articles
    by someone who says "Why OO sucks". Not to mention you got all of these
    links from the same page.

    >http://www.geocities.com/tablizer/oopbad.htm

    This seems to be from some guy in his basement who does FoxPro. So what?

    >http://iraf.noao.edu/iraf/web/ADASS/.../cogginsj.html

    1996 for gods sake. Anything a little more recent?


    >http://www.paulgraham.com/noop.html

    I love articles like this that have this statement -- "From some of the best
    programmers I know". I am the best programmer I know. So what?


    >http://www.bluetail.com/~joe/vol1/v1_oo.html

    This is the best of them all. "Why OO Sucks". Man, that has got to be quality
    stuff from a qualified person.

  15. #15
    Larry Serflaten Guest

    Re: Speaking of strings...

    "Vinay" <vinayc@angelfire.com> wrote
    >
    > "Larry Serflaten" <serflaten@usinternet.com> wrote:
    > >class. So, then, if they made String a value type, that would mean every
    > >call to one of its methods would included the boxing of the value so that
    > >the methods could be called.

    >
    > I was not aware of that value types has to be boxed for method invokation.
    > Any quick links to documentation?


    Thanks for the challenge, I misunderstood the statements I read to the effect:

    "Boxing and unboxing allow any type to be treated as an object." I've seen
    that in many places, one such example is found on a page about value types.
    (http://msdn.microsoft.com/library/de...ClassTopic.asp)

    After looking for documentation to specifically mention the boxing or unboxing,
    I find that it only applies when accessing the methods available to all objects
    (those implemented for the Object interface):
    http://msdn.microsoft.com/library/de...vclrf__box.asp

    LFS








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